Draft 1.2:


Locations that stem from the root-location (usually in the home directory of a system user, or in a root level custom-directly /*X* of the file system) can be used as default data-silos. These silos can help enforce certain behavior within the program and EntityScript™ can map conventions to the data they store.

Here is alittle more about some important program locations


This location holds documentation in HTML or text-based index pages only. The text-based index pages can be in a format such as markdown. Plain-text works too. HTML documentation is preferred. The convention is that if you add section to your program, there should also be 1 associated html index page with an overview of how the section works and what kind fo data it stores. In an EntityScript™ file you're already providing context do the information, so you can use that context to generate a more human-readable overview for each entity you use. Although it may seem like a lot of work, the more you document, the better of your system will be. Store those pages here.

The documentation area also contains distributed documentation for any allowed programming language or extension on the system. For instance, Python distributes an HTML wiki. The wiki for whatever programming language version in use should also be stored here for reference. A simple folder/file format should be applied in the .CORE/DOCUMENTATION/*programming_languge_docs_here* convention.

Even the documentation for EntityScript™ is in this location by default.

Plain HTML/Index form is preferred for package distribution and documentation for system process created by you and the community.

Replace *path* with your desired language location, both laugages, and programming languages.


Each allowed extension-programming language can function inside of C.ORE™, but when you use one besides Python, it should be activated first by making a location in the ALLOWED_LANGUAGE/ location. Because language - as in English, French, etc. is semantic, those languages are also defined here. If you want to allow an additional languge, the translators are placed in this location. If you're using a compiled version of C or some other programming language, the version would be stored in this location library in addition to the version used by your system. Any language you choose to allow can also have the functionality for it stored here but as extension language instead of a system language. This avoids any complicated chroot behavior to get a clean install for the languge functionality.


This has the evolution of the IPDVC™ development and your system can generate overviews of itself that output here. It's not as robust as other version control systems, but it can be used as version control. It will be updated over the years to show how the system came together, or you can update it over the years to see how your C.ORE™ program changes.


The RING handles 5 elements of the system that together will comprise the total range of control methods available to the operator. They are the following:

sub-Location: BACKUP/ for storing binary method-driven backups of your /ENTITY directory and one master .gz archive in a location of your choosing.

sub-Location: DOCUMENTS/ for storing documents in a .ds format that can be incorporated into forms for user input or into other documents as a general component later on. This provides a template library for other common component tasks like "music theory component" would contain a .ds document formatted to be used to re-discover some music theory information that is stored. All documents are meant to be used later on. A 'document' in general should go in ORE/. The preset template types are A.) PROCESSES, B.) AGREEMENTS, C.) TEMPLATES, D.) BACKGROUND and E.) INFORMATION. This summarizes the available standardized templates for specific user or machine-generated tasks.

sub-Location: ENTITY/ the default structure for storing .entity to .ds file relationships inside of CORE.HOST™ and locally, a way to store, alter, and structure your data.

sub-Location: PROGRAMS/ allows you to extend the use of your system without installing anything into the 'root' position of your underlying machine. The default installation comes with the system program environment set for Python use, and airEP™ (ACCESS, IDENTITY, RING, ENTERTAINMENT PLATFORM) allows you to add addtional COLLECTIONS. COLLECTIONS can be programms that run on Python or by utilizing other programming languages. airEP™ runs new programs safely or not at all and a program that doesn't run shouldn't be trusted for use. Certain system calls are not allowed by default. Programmers should not make these calls and rely on other methods. Many programmers don't use these calls, so many of the best software runs fine. Thread protections are in place on the underlying system when possible too. COLLECTIONS allows you to store code-like concepts as a work journal and run riskier stuff only when it doesn't require system resources in an undefined way. These risky programs are not linked into the main AIREP™ thread, thus missing out on certain log functionality and default features.

sub-Location: VAULT_CODE/ holds encrypted entities in the 'MEMORY_FORM' that can be unlocked by access-retrieval methods later on. If you're using some specific encryption method, you would be responsible for maintaining your own system keys for those files. A physical two step if you will, so it's not recommended that you use this section unless you're an advanced user.

Configuration mapping

You can find the following configuration files in .CORE/CONFIG/ and more about them by visiting https://core.host/configurations/: Each configuration is in a standard .ini file, but other types of configurations can be loaded as long as they are implemented in cell-based formats.

Each can be modified and extended to meet your needs. Configurations can be complex, but most of the default configurations are set to send an error when they're not correctly configured. A brief description of what each file does is also provided.

ID location configuration description
1 archive.ini Set archive values
2 browsemeh.ini Set up visual resources
3 config.ini Standard program variables
4 core.ini Standard system variables
5 design_basics.ini Basic output strings to aid with text-mode visual output
6 eventlolli.ini Create event-driven notifications, alerts, and audio visual routines
7 gatekeeper.ini Define access control values
8 interface.ini Set available interface and system variables
9 lockerlinks.ini Set location resources for your machine
10 network.ini Configure network values
11 openpackager.ini Authenticate and enforce meta-check behavior
12 remindme.ini Build time-based variable pools
13 ring.ini Set program enforcement values
14 special.ini Create reusable special resources
15 testing.ini Define testing variables
16 VCN.ini Create a key-based authentication mechanism
17 XYZObjects.ini Set visual parameters

These locations benefit from consistent System Audits and logging. More about System Audits can be found HERE