Draft 1.01:

Sections: Status -> Approved

1.) EntityScript™ Overview - Overview of the project

2.) .entity/.ds Lookups - Overview of basic .entity and .ds file relationships. An overview of each file.

3.) Special File Types - Overview of special types of methods, files, and types in C.ORE™

4.) Log File Types - Overview of Logging within C.ORE™

5.) Using OpenPackager™ - Overview of the OpenPackager™ project and details regarding using the sub-system for organizing the base system and addons.

6.) Locations - Overview of various parts of the IPDVC™ file system

7.) System Audits - Overview of various audit mechanisms present in C.ORE™ and how to use them.

8.) C.ORE™ Scripts - Overview of scripts that run in C.ORE™, the purpose they have, overview of some scripting philosophy, and some usage examples.

9.) Startup - Step-by-step process of startup routines and how to extend them

10.) C.ORE™: AirEP™ file system (Access Identity Ring Entertainment Platform: AirEP™ - Understand more about the Access, Identity, Ring

11.) Keys: Each of the built-in keys that can be used to retrieve meta-information in C.ORE™

12.) How-to: Additional Notes

13.) Moderation: Basic moderation principles

14.) Social Pledge: Basic social-pledge for your interface and who you interact with

15.) Disclaimers: Basic recommendations for your interface and dealing with various types of commerce

16.) Additional Resources: Dig deeper into the technical stack, program methods, variables, and other happenings within CORE.HOST™

Special File Types

The following Keys can be used in C.ORE™ and are available to EntityScript™. To activate various system locations and make them discoverable, you can follow certain defined key conventions or create your own.

Part 1: SPECIAL KEYS -> abstract processes within the system: An abstract process is anything that's defined by the machine without a clearly set identity. A routine or check becomes necessary without having full knowledge of the digital material being processed.

Note*: These following Keys should be used inside of a separate ORE/ folder of your choosing for each needed instance. The default convention is to name 1 folder inside of 1 ORE/ location something random and set them up there. These folders only know that they're processing something unknown. The goal is to use them to get to a type checked and then longer term storage option. This area can allow for strict or casual policy enforcement based off of these special abstract Keys.


Any topics and information that you didn't generate yourself should be located with this Key at the beginning.

This Key should be broken down by meta-topic, meaning - the overarching topic should be the first location, followed by each meta-class under that.

It's recommended that you use this Key inside of the FILTER/ section only and move specific file types into a .ds/.entity relationship.

For longer term "public media" it's better to either symlink to a ORE/ meta-bucket or some other external masked unit-based-pipe. It's not good practice to host these types of files on your main system itself.


This Key is a special instance called the Random Resource Recovery.

Any old, past, incomplete, or broken archive that never reached a finished status can be located more safely in one of these files. C.ORE™ will eventually be setup to scan these folders according to your security/malware policy setup elsewhere.

You may also create recovery folders for individual documents and either fully or partially complete archives. These folders are capable of holding forensics-grade recovery tool output.

It's better to symlink to a ORE/ meta-file than to host these kinds of files directly on your main system.


Any library or script that isn't current or doesn't fit the current specifications enforced by your IPDVC™ goes here.

A general recommendation: it's better to symlink to a ORE/ meta-file than to host abstract processes on the main system.

This is often thought of as the "legacy" branch or the "deprecated" branch of either media/functional file types and may signify a general lack of order of the structures contents.


This represents a archive that has been highlighted as incomplete and ready for immediate elimination. You can also use this to signify a structure as being a work in progress and needing attention. The folders contents should eventually be either a full process or archive elsewhere, or deleted. Anything that isn't finished should have a z_ prepending it really. You can set CORE.HOST™ to not track these in various systems and for various automation routines they're able to be excluded.

Part 2: SPECIAL KEYS -> Program defined or explicitly structured processes

Note* These following Keys are used to make something discoverable to the IPDVC™. They include values of significance and can be located inside of the MEDIA/ multi-part structure or custom linked to discoverable directories.

A.) Storage Keys


This Key is used to signify a compliant storage structure but one that hasn't been certified as archive ready.


This Key is used to signify a compliant storage structure and also one that has been reviewed either by a machine or human and certified as archive ready.

B.) Operations Keys


Use DS before any file to make it discoverable to the datascript_id module, thus allowing it to express itself as a datasheet connector of some kind, which will make it linkable to a desired .entity


LockerLink™ Keys are standard connector objects that archive locations and endpoints to descriptive or qualitative text. They're discoverable to programs within C.ORE™ that use networks or category tagging to function.


LockerLink™-> BrowseMeh™ Keys are standard media retrieval mechanisms that are able to be discovered and processed by the BrowseMeh™ visual display engine. These links are also able to be broadcast as a sequential image library that plays through the module RemindMe™


EntityScript™ ORE Keys are used to retrieve, edit, and delete ORE/ locations.


EntityScript™ Visual Keys are used to retrieve, edit, and delete VISUAL/ locations that handle media files of specified types.


People Keys are used to store locations having to do with someone that you know. They can be used as reminders for birthdays and showing you memories.

Part 3: SPECIAL KEYS -> Protected

Note* These following Keys have special attributes and can be used as something called a 'active qualifier'. An 'active qualifier' makes sure something is happening according to a supplied definition before including the resource and completing the computing task.


A.) Special File types

When you're running a large system it's important that files of the wrong type don't end up places they're not suppose to be with permissions that could under a variety of situations cause harm to external systems plus the machine being used at the time. You want to make sure certain things don't link into the host system. Really, we need to be blocking certain types of forms and functions from linking to the host machine ever. This is a classic "escape" paradox from a system administrator point of view and it's addressed by Special File Types (SFT). They are addressed by structure first and form later here.

Don't copy anything into a folder blindly that has any sort of significance outside of a Special File type to handle this type of situation.

Adding a generic web filter

Sometimes people have personal information in random places and rules are needed to identify that information and remove it. By making sure that anything outside the machine can't come in and if it does it goes into a specific location, we're certifying this can hold up overtime. In terms of web browsing, anything taken in from that device vector should go into a set convention to be destroyed later or isolated from the system as much as possible until stored in a compliant structure.

Take this into consideration when loading in modules or installing extra software. You need to be aware that not understanding the FULL range of permission implications on the base system could easily make many assumptions being made wrong. This happens with other items on the network and so on.

Also, |_| doesn't work right on many OS path resolvers. This then can be used to create special behaviors as a re-linker because of this. The hook for meta-files with different attributes is |_|. You can put immutable objects or other special functioning processes inside of them with less worry. Overall, many file types can go into these filters too. They are here to mitigate attacks to your machine. They are designed to act as mini-micro-kernels. They then can run together in static "universe" files. These files follow these conventions:

In each instance
< OPTIONAL_SYM_LINK > is replaced with the relevant value.

Location: .CORE/FILTER/

There are three main basic filters to help with local enforcement of the above ideas.

Location 1: < OPTIONAL_SYM_LINK > |_|FILTER_+\



Location 2: < OPTIONAL_SYM_LINK > |_|FILTER_+\


Location 3: < OPTIONAL_SYM_LINK > |_|FILTER_+\


The following is the basic FILTER activation.


As a convention, this always prepends or presents at the beginning of a location that's activate the filter.

Additional Protected locations:

These locations can store single state or purpose virtual machines.


MACHINES contains other peoples stuff, mainly for reference on various topics or materials. You can use this as an assembly bin for compiling new combined works. This folder doesn't bundle with any of your creations. Your creations get shared through an entirely different sub system in the IDENTITY/ folder.


COMMUNICATION_RULES contains virtual sharing system rules. They can assemble torrents, allow webcam or microphone, allow network access, or decide if paths to other "end-nodes" are allowed. An end-node would be something that receives some I/O connection and sends back a formatted response. This rule set also allows for you to map the way your system speaks to the world. It allows for either direct discovery or connection utilizing various proxies.



DECIDER contains basic definitions for blocking adult content and disabling various features. Defaults to block.

Extending the metal

Part 4: SPECIAL KEYS -> System Keys

.dugout files

Your .dugout/run_program.dugout file must define some additional variables to get program extensions working at startup.

Here is an example utilizing *Details coming Version 1.1* and a *(Details coming Version 1.1)* environment, a pretty common setup.

1. You need to post the full path to the ORE/ directory setup elsewhere that holds your virtual *(Details coming Version 1.1)* environment and name it something, like 'JUP_DIR'. Certain configurations will need to be accessed and changed to meet this location, but it that's done, you can keep adding more and more ORE/ files for different activity. So, instead of then running these programs directly on the machine, you run it virtualized in the IPDVC™. So to continue with this example:

entry: JUP_DIR=/run/.../ORE/XA**47/

Now, in ACCESS/ you can generate new definitions locating each needed file type>

2. You need to setup a macro to get the program running at startup or tie a start function to it using a setup script. This will make it accessible to active qualifiers that will run it in the right way. Name the routine something simple, like 'jup'

entry: alias jup='cd $JUP_DIR;source jps-env/bin/***; *RUN/START COMMAND COMING IN Version 1.1* --cer*****=

~/PROTECTION/jupcert.*** --ke*****=


3. To activate it, simply run:

$ jup

Or, you can just tie it to a setup script or other routine entirely.

You'll have to self generate the .***/.*** pairings and that can be done utilizing other guides.

If done right you can have an extension made available in the right type of system container to throttle any resources to it that you would like.

To see more about the Logging and Auditing in C.ORE™ click HERE