EntityScript™

EntityScript™ file specification

EntityScript™ compliant files can be created manually or by using the automated .entity generator. New Entity Operations Inc. designs and maintains a variety of EntityScript™-specific tools to help create, manage, index, and retrieve mass-quantities of these structures for automation purposes.

Default-structures are recommended to achieve optimal Cerebral-recall. The default cerebral-mappings can be found in EntityScript™ Cerebral-structures section

Example EntityScript™ (.entity) file

## DS0000001.ds - Created by: K3PNQHB721EM

KEY::: entity_id

## Entity Snapshot
datascript_id = ['entity_id']
title = ['EntityScript™ Generic Structure']

## Package Snapshot
package_type = ['indexer'] # can be indexer, contact, or game
package_id = ['NHHGE35IOP32NH']

## Directory=> List-file
DLIST = ['DS0000001.ds']

## Index-List
INDEX = [
    "entity_id", "entity_category", entity_path", "entity_meta",
    "description", "entity_manifest_id"
]

## Identifier Overview
identifier_type = [
    ('entity_id', INT), ('entity_category', TEXT),
    ('entity_path', VARCHAR), ('entity_meta', CHAR),
    ('description', TEXT), ('entity_manifest_id', VARCHAR)
]

## Datascript Module Context
datascript_module = [
    ('entity_category', 'ENTITY CATEGORY',
        'What category best describes the Entity?'),
    ('entity_path', 'ENTITY PATH',
        'What is the path of the Entity?'),
    ('entity_meta', 'ENTITY META ACTION',
        'What meta-action is this folder permitted to perform?'),
    ('description', 'ENTITY DESCRIPTION',
        'How can you best describe this Entity?'),
    ('entity_manifest_id', 'ENTITY MANIFEST ID',
        'What is the Entity Manifest ID?')
]

## INCLUDE - Additional modules that were included
include_module = [
    ENTITY_PARSE_COMPLEX.py
]

About .ds to .entity pairings

Compliant EntityScript™ files have each of the following sections, but .entity files also may be extended to the index information provided in a seperate file of any structure (.csv, .json, etc.) as long as the keys in INDEX match. ↓

EntityScript™ .entity meta-component specifications

These are the .entity file meta-components of an EntityScript™ file. Each of these represent a machine-significant string that is intended to be parsed at or prior to runtime.

Header information:

The header contains information about the dlist and creator. The creator key is valid if it is a 14-digit VCNKEY™ or a resolve-ready url is provided with information about the creator. This information is considered meta-data for the file.

KEY:

The default entity-key (as in id field name) representing a local-region identifier. Local-region identifiers are not globally unique, making them secondary to fully-resolved primary indexs provided by sites like core.host™.

datascript_id:

A datascript_id linker is used to associate linked indexes locally or purposely segmented sub-component structures into index-groups. These ids are usually the same as the 'KEY' but occasionally it will be broken apart into separate 'meta-KEY' sections to create contexual scope when enough entities are linked together. datascript_id can also be masked through obfuscation masking the primary-id index of a structure for privacy reasons.

title:

The human and machine readable title of the the .entity construct. The title holds no value outside of programmer or operator dependent context as all EntityScript™ information is parsed according to INDEX values and meta hierarchy of collective system scoping. However, a title can used for locally-unique, intranet-unique, or global-unique constructs for a given associated datascript file.

package_type:

The defined package_type that conforms to the OpenPackager™ distribution standard. The main and default package_type is an 'indexer' which will provide for basic key-value lookup options between .entity and .ds files. Because real-world humans are considered protected classes within EntityScript™, any real person is considered a "contact". Additionally, anything that is neither "real" or "data" is considered a "game". Think "game theory" not sports. Games are complex and unique in nature.

package_id:

This is the 14 digit hash chosen for the storage of the entity. Although 14 digits is standard it can be extended or reduced according to the needs of the user. When a .entity is bound to a system such as core.host™ the package_id is the posted public identifier, not the title. These "slugs" are where packages sit when being vetted and exchanged amongst peers.

DLIST:

The D-index List file or 'DLIST' is the 7-30 digit id number of the .entity template file that's created designed to store a datastructure of a provided type (.csv, .json, .xml, etc.). All 'DLIST' values are prepended by the reserved-key DS and will end with the default extension for a standard datascript-linked entity file, i.e. '.ds'.

INDEX:

A list of all available lookup-keys. These are able to be used in any programming language that parses key/value pairings.

identifier_type:

This is the list of tuples that provides human-readable or machine-context to your linked DLIST INDEX structure. The tuples each have two positions, the first being the lookup location and the second being the enforced policy of that location as a key. These enforcements take on standard data-scopes such as INTEGER, CHARACTER, VARIABLE CHARACTER making them compatible with databases of all types. identifier_type helps make .entity/.ds available for various traditional data-storage systems when needed or able to be used as an enforcer of data-type before commiting data to permanent storage. There are only strings and integer types in .entity and .ds files, but through using identifier_type, you can enforce more types before commiting that data to a database transaction.

datascript_module:

This is the list of tuples that provides human-readable or machine-context to each identifier_type other than the primary ID key. These list-items are meant to be readable by an LLM and able to be activated by local-first agent tasks as a result. Each tuple has 3 positions only. The first is the lookup-key, followed by the lookup-key label (displayed in a graphical interface), and the third is a help question (LLM-contextual provider) to allow a quick overview/understanding of the lookup key datastructure. The stronger and more concise your datascript module descriptions, the better an LLM will be able to make use of the structure for automation tasks.

include_module:

Here you're able to associate multiple other datascript_id sections or linked program runtimes to the file. Include modules present secondary branches and are considered descendants of the package_id. You're able to add a variety of programmer defined extensions.

EntityScript™ Escape Codes

Each `protected` EntityScript™ string can be swapped at the character level in the file itself using the following convention as a manual or program-driven override

The .ds file-container

PATH: ..datasheet/..
Overview: A datasheet is not datascript. datascript is the identifying prepender of a .entity/.ds file relationship represented as DS. A 'datasheet' is the extension/representation of a file-container that is referenced by this prepending DS key in a .entity file. A DS key is a discoverable meta-key inside of EntityScript™. 'datasheet' only means a file-container holding unspecific data-types.
Usage: Store the .entity/.ds relationship to safeguard data relationship by enforcing valid syntax and defining that syntax/context within the .entity file.
Includes: .entity FILES, .ds FILES, AUTOMATED PROCESS GROUPS (APGs), STAGING DOCUMENTS, FIGMENTS, and various additional personal data media formats
Examples of STANDARDIZED parts: .entity/.ds are special formats, while wide-spread formats are considered standardized (.json/.csv/.txt) and can also be represented as a .ds container.

Symbolic representation and licensing thought-structures

As a pair, the .entity/.ds relationship represents a "DIGITAL ENTITY ASSET (DEA)".

A Digital Entity Asset™ holds asset-specific relationship descriptions, structures, and machine-readable models that can be run in a C.ORE™ EntityScript™ processor.

EntityScript™ processors can be built by manually designing .entity files or by using pre-built pairings instead. A completed .entity/.ds meta-structure is unique to the operator that assembled them and it will change based upon the recall needs of the person that designed the structure. A preset program and asset bundler (PAB) provided in the 'creator' module allows you to build a .entity file by following a prompt. When the prompt is completed a .entity file is created but in order to activate that file you must name a .ds file the same thing as put it within a nested datascript directory. EntityScript™ links these two files together automatically by association. A minter is provided to 'lint' this pair to make sure it holds the correct format.

Some of the provided .entity file run on non-clean licenses once you link .ds containers data. The license of the pair is not dependent on each other and sometimes a .entity and .ds pair will hold different licenses. Many licenses are available for personal use only or provide basic copyright protection by default for various other reasons. When something is shared it must have an appropriate license to be reused by peers, and when you are dealing with commercial-use, additional considerations must be taken.

Certain licenses that are appropriate for open-source software are not appropriate for .entity/.ds pairings. All original content that's licensed appropriately for reuse can be shared on core.host™.

.entity files that are created by you and not shared should be assumed to have copyright protections by default. This applies to all of your own personal data too. Your information is intended to be owned by you when it was created by you, and when data you have on your machine was created by someone else, it defaults to having copyright protections for them. With this being the case, some information-structure types may still be unable to be shared or will be restricted from sharing on CORE.HOST because they contain intermixed copyright data that doesn't legally work when being combined with certain open licenses that strip the original copyright away from someone elses work. For these reasons it is important to only share work with open licenses that you created yourself and to not copyright .entity/.ds pairings that intermix other peoples copyright-protected property.

Take down decisions when a dispute arises is up to the operator that owns intermixed copyright-protected work within a pairing and also up to New Entity Operations Inc. upon review. When you create and share these pairings or even just singular .entity or .ds files, you'll have to make your own decisions as to any warranty about the service of such files in production - including the integrity of the data itself. Reputable data should be preferred over randomly compiled anonymous sources.

EntityScript™ archives won't be able to allow certain licenses requiring New Entity Operations Inc. to not act in required ways that comply with copyright law. If one of these licenses is linked or bundled in that invalidates those protections, depending on the situation - it may need to be removed. As a rule of thumb, systems and creative tools work best when the operator provides straightforward 'copyright (C) YEAR Owner' style releases. If a certain permissive license is available for that work, it should be appended to the original copyright statement.

Allowing direct links to certain license types is risky within your work because it could link you to the license that you are linking to. This is moreso a concern with copyright invalidating licenses or copyleft license designs. Various Public Domain style licenses are also not allowed under a variety of commercial standards. Nothing against public domain work, but within the commercial arean, they are generally not allowed. Public domain licenses should be thought of as as being best designed for personal use with certain scenarios that allow them to be used in commercial activities. Any of the licenses that fall into these silos are safer within the personal/community distribution realm.

If you have licensing concerns, create a virtual machine and plop the pairing inside of it. Run that pair as an independent process and call to it in an unlinked manner. This is more practical within a 'closed environment' testing scenario than in production.

Sharing certain formats may be deemed a 'redistribution' and if the materials are sensitive, it could get you into trouble. This includes classified information, owned data, or unathorized datasets. Be mindful that these pairings were created as a way to organize YOUR information not other peoples, and license-based considers are now being presented as a secondary consideration only. With that said, the license considerations are intended to allow for production use, shaing, and reuse of community .entity/.ds pairings.

A rule of thumb would be: Anything that you think may be unsafe to be shared to the public should remain a Personal Entity File (PEF) instead. You can mark within the meta-data *PEF anywhere in the header to enable this format.

These personal file distictions won't allow for sharing unless an override is achieved during the pulication process. This is one of two symbolic distinctions that need to be highlighted. The second distiction is symbolically called a World Entity File (WEF) and it should be thought of as public even when you're establishing some sort of access protection using passwords or keys. Again, to enable to it, put *WEF anywhere in the header of a .entity file.

You should ensure that your machine has been isolated correctly before working on sensitive materials for work. One way to do that is by utilizing the container system in New Entity OS™. Installing the current implementation of C.ORE™ on a fresh installation is the best way to ensure the system still has integrity. Ad-hoc systems that have been in use for years may or may not be suitable for such computing tasks.

EntityScript™ is meant to provide resources to the operator as a implementation philosophy, not act as the system of last resort for every situation. New Entity Operations Inc. and affiliated groups take no responsibility for these types of creative decisions, including the implementation chosen for EntityScript™ in a chosen programming launguage outside of offical releases. It's recommended not to use public wi-fi while working on your own data either if it is considered sensative. Various mechanisms are present to mitigate some risk of these scenarios within official New Entity Operations Inc. software releases.

Non-production environments can be set up with other tools and software like you may design and build out a standard linux-based machine, but EntityScript™ is meant to be a personal software tool that provides the full range of utilities when combined with C.ORE™. First and foremost these two pieces of software can be treated as a full system programming interface that only needs a kernel and user-space to run.

'Virtual Entity Package' (symbolically called VEPs) can also be designated within the header of a .entity file. This unique distinction has a corresponding environment file/setup definition stored in kernel-execution space that tells the program to containerize the .entity before execution. Container enforcement is controlled by your operating system and implementation language of choice, not by C.ORE™ or EntityScript™ directly.

The default programming language chosen for user-space modding in C.ORE™ is Python 3.10+. The 2026 version relies entirely on Python and Shell (Posix implementation).

entity files also can be tied into an explicitly linked C.ORE™ routine through a program-processor. These program-processors provide additional functionality to the end user to help complete a variety of tasks. Linked modules are scoped within the 'operations' construct of C.ORE™ the 'interface' section allows you to map them to user-space interactions.

System tools need initializing programs to handle shell functions and virtualization. Again, this is handled by kernel-space handoffs. One of these programs is required to run the default programming language and operate various shell commands including virtualization.

Some programs that you build with EntityScript™ are system-level, meaning you should be careful when running them even though they are read-only. Read-only is about execution limits, not about access and modification of system resources.

Some programs that are available have been compiled from source or explicitly installed with a managed virtual-environment. Make sure you're familiar with whatever language you decide to use to extend the New Entity Framework™ provided here.

Installing additional .entity/.ds pairings

You can install additional .entity/.ds pairings by extracting them from the 'X_fullname.ARCHIVE_TYPE' file into the RING/PROGRAMS/* directory. Depending on your platform, you can also install them manually into the provided structure by putting a .entity file in a entityMetaRoot and a .ds file in a nested datascript silo.

Both methods store activated programs. If you're looking to develop an extension yourself, you should package it into the provided structure format before exporting it. Extensions are modules within RING/PROGRAMS/* and when you are running them as raw-pairings, they are made available to EntityScript™ through the provided structured paths.

EntityScript™ modules that you own or have created will go in the .CORE/RING/ENTITY folders as run as raw pairings. When you share them, they become RING/PROGRAMS/* modules by default which compresses them.

If the module also includes a custom implementation language extension, it goes into the linked-module area /CORE_PATH_HERE/OPENPACKAGER/. OpenPackager™ sections are customized to bundle completed or complex-linked share-ready programs.

Packages running in OpenPackager™ are in isolation by default. They use a system runner to execute their bound/linked programs with a kernel-specific initializer and setup scripts. One method of extending these OpenPackager™ programs is with /CORE_PATH_HERE/OPENPACKAGER/corehost or by providing additional functionality to other programs as a binary.

Environment variables are linked to program setup files regardless of the implementation language in use through your shell environment. These linked-shell environment types are either directly accessed in the C.ORE™ program or through a OS shell interface program.

ABOUT ENTITY: .entity file type

.entity files are a standardized structure described in /file-specification/. However, you can also use additional meta-data such as a block_hash_id and a creation_timestamp if a storage of record is required for the file. Additional information about a proposed EntityScript™ storage of record system is also described later in the document.

Please consult those additional readings on how to utilize these storage of record concepts. The standard way of accounting for storage-of-record data may or may not meet your needs - you can simply implement your own or use additional methods of your chosing if they do not work for you. The standard record management directives work best as single purpose storage containers that are readable with exactly 1 byte size attributes or in the case of complex identifiers, up to 32-byte headers. Read-only pages are rendered from those identifiers and record tasks can be audited depending on the byte-value you settle on. Byte-based read-only 'storage-of-record' takss can be be programmed with more functionality and extended too but a basic version is also provided below. In the event you use the presented system, meta-relationships are utilized with standard types and reserved keys. These types and keys are what make EntityScript&trde; key-based by default. Together, all the keys and types form the basis to Special File-types which make EntityScript™ extensible.

Special File Key-types

Special File Key-types are used in C.ORE™ and can be linked to EntityScript™ runtime behaviors. Each special type is a pre-built construct designed with generic computing tasks in mind. To activate various system locations, directories, sockets, or similar and make them discoverable for a variety of context-specific functions, you can follow certain defined key-conventions or create your own location-contexts utilizing each default key. You can also build your own.

Part 1: SPECIAL KEYS

Special keys are abstract contextual-processes within the system that are standardized control-based structures. Abstract processes are anything that's defined by the machine without a clearly set identity. In a traditional cell-based data-format like what's made available in JSON, CSV, and XML these are irrelevant, but if you use a special key to prepend a directory, it is activated according to the special keys purpose. A special keys purpose is a routine or type-checked behavior according to a desired digital process objective. Some of those objectives can be summarized by the following pre-defined keys.

Note*: These special keys should be used inside of a separate ORE/ folder of your choosing. The ORE/ location-structure exists outside of the default /CORE_PATH_HERE/* location. It's recommended that the ORE/ location of your choosing be on an exteneral drive that has an automated backup routine attached to it. New Entity AI™ handles a lot of the external processes and shell functionality for C.ORE™ programs. ORE/* takes on the form of XA* conventions by default. XA* conventions are considered special compliant data-structures even if it houses 'raw' files of the unstructured data-type. XA* directories are discoverable within New Entity AI™ as the default discoverabel data-silo convention. These XA* keys are directories/folders can be instance wide, or ORE-based. For instance, only 1 ORE/XA* directory at a time can deal with on the fly data-processing of undefined types if it has a unique name. However, if you have multiole ORE/* locations with the same XA* naming convention, they are processed as independent data-structures.

ORE and EntityScript™ don't know what the data inside of them means. EntityScript&rade; only knows that something unknown within the structure is being processed. The goal is to use special keys to get to a type checked component before processing of any type can occur. These types are established within each compliant area for future I/O resources that process the key according to pre-defined methods. These methods make assumptions about the data within the structure. The keys are also meant to be human-readable so you can process the data within them manually with human-methods as well. The goal is to automate the processing of these data-types beforehand by having a strict definition of the stored-data structures within. The provided special keys should give you the required context to make informed decisions about what to do with the data in the location. These contextual-areas allow for strict or casual policy enforcement too based off of these special abstract Keys. The enforcement is handled elsewhere by both C.ORE™ implementations and the kernel-level behavior.

AAA_

Any information that you didn't generate yourself.

This AAA_ data should be broken down by meta-topic before being moved to permanent storage. AAA_ is considered a canidate for long-term recall-based storage: meaning that the overarching topic should be stored first, and any meta-topics should be branched outward from the root topic.

AAA_ data uses this Key inside of the FILTER/ section when dealing with public internet-specific data. If AAA_ isn't within the filter, the data is considered vetted and ready for review and potentially moveable to recall-based long-term storage.

For longer term "public media" it's better to either symlink to a ORE/ meta-bucket from a filter, or to some other external masked unit-based-pipe. Public media is undesirable in EntityScript™ unless it is explicitly licensed. It's bad practice to host random public media types or files on your main system. You shouldn't save anything from the internet unless the license and legality of the data check out for long-term storage. Nothing that doesn't pass these tests should ever be moved beyond the FILTER/* construct.

RRR_

Special instance called the Random Resource Recovery units (RRR_) are for storing potentially suspect files. RRR_ directories will automatically turn each content into a read-only archive stored by the correct kernel-protected user/perms scheme.

Any old, past, incomplete, or broken archives that never reached a finished status, recovery data, or virus, malware samples can be located more safely in one of these files. New Entity AI™ provides ways of handling malicious content by default and it should be deferred to when making sample-storage decisions. These structures are muted/non-discoverable by default and on Unix-like systems they have permissions enforced according to a strict security-friendly methodology. C.ORE™ implementations scan these folders according to your security/malware policy setup elsewhere usingn industry standard scanners. If you're doing a data-recovery, it can start in one of these key-based destinations.

Recovery key-directories can also be utilized for individual documents that are either fully or partially complete archives of data. These directories are capable of holding forensics-grade recovery tool output too.

It's better to symlink to a ORE/* XA* meta-directory than to host these directory-locations directly on your main system and access them either through the FILTER/* or via a virtual-interface.

YYY_

Vetted but still unprocessed data

ZZZ_

Libraries, directories, files, and sockets that don't fit the current specifications enforced by your IPDVC™. Think of the ZZZ_ key as something that will eventually be destroyed or moved to a more appropriate long-term storage location.

It is better to symlink to a ORE/ XA* meta-directory than to host abstract ZZZ_-based content on the main system.

ZZZ_* can also specific a "legacy" branch or the "deprecated" branch of data. Media/functional file-types that have no structured-content ordering also should go in ZZZ_ key-locations. In C.ORE™ implementation they're a lower-class of data-type and would be expected to house non-storage-grade data by default.

z_

This represents a archive that has been highlighted as incomplete and ready for immediate elimination.

You can also use this key to signify a structure as being a work in progress and needing attention in the shorter-term. The z_ directories contents should eventually become either a fully processed archive, or archived elsewhere in another key. If z_ keys aren't ready for archiving and won't be, they should be purged. Anything that isn't finished yet that's important should have a z_ prepending it. CORE.HOST™ doesn't track z_ keys for various automation routines. In C.ORE™ implementations they're able to be excluded entirely.

Part 2: STORAGE KEYS

Storage keys are defined to store data in long-term and recall-based storage locations. These keys are explicitly structured contextual-processes that are meant to achieve the archiving and discovery of various type of persistent data.

Note* These Keys are used to make something discoverable to the IPDVC™. IPDVC™ tracked assets are meant to be reused and rediscovered again as a type of virtual-memory. Virtual-memory can be utilized by agentic forces within your machine.

These keys should either be located inside of the MEDIA/ multi-part structure, or custom-linked to discoverable directories within ORE/*.

A.) These are generic 'STORAGE KEYS'

XA_

A compliant long-term storage structure. However, XA_ keys aren't considered as certified as 'archive ready'.

XAA_

A compliant storage-structure and also one that has been reviewed either by a machine or human and certified as 'archive ready'.

B.) These are generic storage-based 'OPERATIONS KEYS'

DS

DS can be used before any file to make it discoverable to the datascript_id module. This allows it to express itself as a datasheet DATA SLUG connector - thus making it linkable to an existing .entity file.

LL

LockerLink™ Keys are standard connector objects that archive locations and endpoints to descriptive or qualitative text. These descriptive texts should also be functional, such as URLs, file-paths, or permissions. LL* locations are discoverable to programs within C.ORE™ implementations that use networks or category tagging to function fully.

LLB

LockerLink™ BrowseMeh™ keys are standard media retrieval mechanisms. LLB* keys are discovered and processed by the BrowseMeh™ visual display engine within C.ORE™ implementations. These links are also able to be broadcast as a sequential streaming-image library that plays through the module RemindMe™ that displays time-dependent images and multi-media on a variety of digital signage.

ESO

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

ESV

EntityScript™ Visual Keys are used to retrieve, edit, modify, and delete VISUAL/* locations that handle media files of specified types that stream real-time visual data to digital signage.

PK

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 PROTECTED KEYS

Protected locations allow you to silo or isolate content types according to regulations or safetey

Note* These special protected keys have have special attributes allowing them to use a 'active qualifier'. The 'active qualifier' mechanism within C.ORE™ implementations makes sure something is happening according to a supplied runtime defintion before including that resource into an active runtime. Automation routines are processed by completing the computing task without human input so active qualifiers are used to determine what can run and what doesn't achieve active 'state'.

A.) Special protected file types

When you're running a large system it's important that files of the wrong type don't end up in places that they're not suppose to be.

File/Directories/Sockets in unauthorized zones can cause harm to external systems through a variety of 'contagious processes' such as unauthorized access. Each machine being used to run C.ORE™ implementations are relevant because they handle processing kernel-specific data differently, but all linked-machines are also important when they're communicating amongst each other in real-time.

You want to make sure certain processes don't link into the host system ever so the special protected file types were designed as a virtual-machine extension. By default, these are isolated. You are blocking certain forms and functions from linking to the host machine by using various filters. A "escape" paradox is used from a system administrator perspective. This helps Special File Types (SFT) existing within one of these filters to be blocked from escaping their current location which is viewed as a type of root archive location. Some SFT locations are excluded because of the type of content they hold, even though this content might not pose a security risk.

Don't copy anything into a directory from a SFT blindly. A generic web-filter can be used as a pre-vetting area initially. 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 minimizing the surface area. In terms of web browsing, anything taken in from this vector should go into a FILTER. All FILTER data can be destroyed upon powering down the machine, or you can automate a routine that stores it into a ZZZ_ style archive elsewhere. Eitherway, public data should always be isolated from the core digital long-term storage within C.ORE™ to prevent lapses in system integity.

Also take this into consideration when loading modules or installing extra software from popular software hosting sites. Just because software or modules are hosted on a popular site doesn't make them secure. For this reason, you should also treat them as data that should be isolated within a FILTER until they receive additional reviews. You need to be aware that not understanding the FULL range of permission implications on the base system could easily make many assumptions that were made wrong. This happens with other items on the network too and with modern programming tools, it can be hard to know when a harmless program can become a vector for expliotation in the era of agentic operations. Filters cut down on this risk because Agents can't use the network with content placed within them.

|_| doesn't work right on many OS-level path resolvers. This doesn't make it safe, but it does cut down on a large surface area in path-discovery.

We use |_| to protect various *PATH* attributes and declare a filtered location. The filter-hook for meta-files with different attributes is always |_|. You can put immutable objects or other special functioning processes inside of them with less worry of them being able to later expliot your system. Overall, many file types can go into these filters too as well as default public data and media. Really these fitlers have two functions: security and obfuscation. These are made available to mitigate attacks to your machine, not stop them.

Filters should be designed to act as mini-micro-kernels for the path finder in C.ORE™ implementations. They then can run together in static "universe" files that only knows how to talk to other filters. These files follow these conventions:

Location: /CORE_PATH_HERE/FILTER/< OPTIONAL_SYM_LINK > and there are three main basic filters to help with local enforcement of the above ideas.

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

DECIDER: contains basic definitions for blocking adult content and disabling various features in a family-setting. Defaults to block. As a convention, virtual-interfaces are also stored within a decider. These deciders always prepend or present at the beginning of a location that's activating the filter. Additional protected locations store single state or single-purpose virtual machines.

Location 2: < OPTIONAL_SYM_LINK > |_|FILTER_COMMUNICATION_RULES

Location 3: < OPTIONAL_SYM_LINK > |_|FILTER_MACHINES

The following is the basic FILTER activation convention and it can be extended into more custom filter-types.

|_|FILTER_

|_|FILTER_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.

|_|FILTER_COMMUNICATION_RULES contain 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 to EntityScript™ rulesets. It allows for either direct discovery or connection to processes that may or may not use the network utilizing various proxies.

|_|FILTER_ADULT_CONTENT storing protected adult-themed content and enforcing parental controls

Part 4: protection keys

Protection keys are utilized by New Entity AI™ to provide additional layers of protection for local-environment tasks and runtime attributes.

.dugout files

Your .dugout/run_program.dugout file must define some additional variables to get program extensions working at startup. In C.ORE™ routines ACCESS/ can generate new access-based definitions for running and accessing runtimes. The ACCESS/PROTECTION/* paradigm can be used to store local-keys.

Alerts and Logging in C.ORE™

Use the built-in user-space audit framework that helps your isolate computational-processes into observable parts. Here is a brief overview of how that works.

Log File Types

Logs are automatically generated by the C.ORE™ program and adhere to a thread-based model that establishes rules for each running sub-process before hand, where each thread is a potential to log a process. Each process can be stored as they occur and they are defined storage outcomes when the audit framework is in place around the specific code-block. These outcomes are segmented into silos when logged and some are set to on/off by default, but more be generated.

Each logged silo works based off of user-defined types. Some of those types are presets and self-created at the programs startup. Others can be selectively turned on.

At any given time while the program is "up" there is one main process running. By default, async behavior isn't included but can be branched to a async process handler. There is also a personal instance server that survives base program termination and runs as a separate process until it's killed manually. This methodology can be made so it only operates while the program is in an up state. Each running thread is able to process data as if they were sub-states because they aren't blocking. Only 1 process runs at a time by default - unless multiple instances are activated. This is a possiblity.

Each process isn't bound to each other at all. Instead - processes are linked to each other. These states can be branched or forked into new kinds of behavior too. Running under a read-only stateful sub-system, these silos provide a way to group outcomes into log like storage containers easily. Read through the .CORE/core_alerts.py file for more details and for relevant doc string overviews regarding functionality.

These log file silos should all be wiped and set back up at set intervals. They should only be run based on scripts used in the extensions sections and tied in correctly using a connector object of some established convention type. The operating system in use underneath everything can change each added behavior slightly and will cause some different methods and processes to run slightly different on each system as they occur. The way processes run on each machine may vary slightly too depending on the virtual environment chosen and hardware. It's not recommended to add any random behavior to the logging framework or to try to implement your own logging routines. It's better to follow the provided framework - the framework provides any type of needed auditing. Follow the set computing-transaction methodology available in the preset methods for activities, events, and searches.

Logs are meant to be processed every few days. Ideally, that process should strip the necessary information from the log and reset the file to a base instance. A base-instance is considered "clean". A clean file is also used to describe any other type of storage container that is EntityScript™ compliant. An EntityScript™ compliant data container takes the extension .es. By default .es files that are generated are stored in DATA/. The data kept in each container should be of an exact type and be stored for an exactly defined software process existing within the system according to a time-schedule and operations enforcement criteria. These time schedules can take "Alerts". All "Alerts" are the way that common data-type events flow into .es files, even when they aren't explicitly logs of each of them in detail.

Default system activity logs to 1 and only 1 file that exists in DATA/ACTIVITY/.

This file is significant and can be used to generate general automation routines. This is a log file, the only defined one from the state and simply is named log.es

There should be zero extra files in the .CORE/DATA/LOGS/ section once automation and processing of those types for log-specific files occurs. By default, your logging behavior can be branched into this location and can serve as a web server logging mechanism, system event logger, a firewall logger, and more. Only data that has already been processed and archived according to an exact format should remain here after these automation routines occur, because it's meant to exist on the fly. Any other logging-based file that isn't processed through C.ORE™ should be isolated into a "unprocessed bucket (z_ or ZZZ_)" and went through by a human according to set "archiving" principals.

If there are any extra logs that aren't "cleaned", you're behind in a way that can get the machine into trouble later on. Logs should always be processed and cleaned according to the desired time-interval and long-term storage objective. This helps the operator get accurate and timely insights and also helps keep the system current.

The goal og the audit framework and logs is to have a parser for each type of log that produces general yet descriptive output.

These logs then are written into longer-term storage according to an exact time-schedule. All of these logs should only exist within:
.CORE/DATA/LOGS/*

Data containers table

All data containers are stored in DATA/ besides the exceptions of log.es or other log_*.es files stored in DATA/ACTIVITY/ or DATA/LOGS/

There are preset types of data that you can store:

blob General multi-data unstructured or undefined I/O processor logs

cache General on-the-fly data process logging, usually temporary in nature

communication Server communication logs

communications Personal server communication logs

entity-output formatted output logs

entityscript-ore Retrieval-protected logs of various types

fed-by Logs that are being pulled in from other generated log access-points

output-flush Logs that are ready to be flushed at the start of a new instance

output-slug Logs that meant to process a constructed class data output module

output-structure EntityScrtip™ compliant logged structures

output-vectorized-data Vector-ready compliant logged structure

structure A log type that allows the feeding of another log

system-lookup A system generated log from a processess that was pre-defined by the program

system-routine Automation focused logs that are kicked off by a machine process

vcnkey: The output of a block-transaction with CORE.HOST™

OpenPackager™

OPENPACKAGER™ is a way for your system to use any extension program without installing them into your main machine. Similar to containers, yet unique in various ways because each container requires a checksum verification to initialize.

You're able to Tie real (as in a program with functionality) and fictitious entities (as in a EntityScript™ template designed by an operator) to enforced context modules that utilize the .entity to .ds relationship. These modules can installed in a special location that will then enforce verification that the version in use is the one you're intending to use, and not one that has been altered somehow during download or setup. If it's not verified, it won't start. OpenPackager™ keeps tracks of active versions key-hashes and then enforces those hashes before runtime.

Using OpenPackager™

A variety of different environment choices can be made within your system. Each system will have some sort of kernel and some sort of boot-related program that links the system hardware to the software of the Operating System.

It is recommended that you use the smallest possible blueprint for the kernel and the hardware initializer sub-system. You should follow up on this methodology by being conservative while implementing any additional system-level packages. It is even recommended that you use some sort of security module to make sure a program doesn't have scope or access to system resources it shouldn't have access too. Some popular ones are SELinux and AppArmor.

System-level packages should only be installed from trusted publishers. Trusted publishers are not random open source developers. Although their code may be cool or useful, these programs should be installed in OpenPackager™ and not at the system level. If the publisher isn't trusted (although they themselves may be trusted as a person and have integrity- the software may not be vetted to the standard of 'safe to use in production'. 'Safe' is subjective, but objective criteria can be used when determining if something is safe for system-level installation or not). It is important all packages at the system-level conform to some higher standard of system security. This usually means these programs are open-code, even if they're not open to modification by a specific vendor. These practices can be enhanced more by adding additional middle-layer control packages and saving user-space packages for OpenPackager™

OpenPackager™ extends trusted programs into a clear user-space package control framework. This framework can terminate these packages while in use without modifying the state of the C.ORE™ program - and each OpenPackager™ runtime is a second-order program inside of C.ORE™. EntityScript™ provides templates to enforce the proper controls of added packages, both at the system-level and at the user-space level through OpenPackager™.

OpenPackager™ favors programs being extended with additional meta-class related behavior that themselves run as single use processes. Blobs are considered poorly designed if specific threads can't be inspected with the default audit framework provided by EntityScript™.

To search for new packages, OpenPackager™ uses CORE.HOST™ to retrieve, install, and manage external package checksums using something called a VCNKEY™. A VCNKEY™ is a multi-purposes block-generated token that can act as part of 3 part verification system to run packages in a more secure fashion. The other two parts aren't covered by EntityScript™ because they're handled by a program called TRINE™ - something that communicates directly with any block-related program and stores both the public-key of a block transaction and the user-party associated with that key. TRINE™ then acts as the endpoint where you can contribute your credentials to verify that you're able to interact with the 'universe' you're querying.

Your system may use your own distributed and controlled branch locations even if they haven't been made available to the public through CORE.HOST™. OpenPackager™ also uses private locations to retrieve system level packages trhough some kind of virtual environment. If a program is not in a virtual environment, it won't run with a valid checksum. A program with a faulty checksum is not able to be accessed by C.ORE™.

CORE.HOST™ was designed specifically to distribute and provide access to OpenPackager™ compliant entities.

More programming languages can be used besides the one chosen to implement EntityScript™ (Python) but they'll be expected to hold true to various established conventions.

When distributing packages, the operator takes responsibility about how this software interacts with both the graphical system and the underlying sub-system. Some code doesn't require UI features, but other programs do. All UI systems are implemented indepently of other UI systems, so it is preferred that UI components that are in use are of a somewhat universal standard or type. For Linux, something that is X-based will always work okay.

Additional code that's added to kernel itself doesn't rely on the same checksum process, but the behavior falls back to the kernel-level program management ecosystem in place. EntityScript™ and C.ORE™ do not determine what is a valid system-level program and what isn't. They do however determine what is a valid system-to-user-space hook for additional program behavior. The sub-system that does this takes you all the way into the metal with a software-layer and OpenPackager™ makes sure some basic details are in line before it'll allow your system to allow for that kind of program to run.

The following conventions for OpenPackager™ are relevant to this methodology:

Location: .CORE/OPENPACKAGER/

There are two preset environments for this established convention. The first is corehost and the second is external

Whenever programs in these locations make system calls, they should also have some sort of logging mechanism attached through the audit framework. Activity from each of these program can either be generalized in the activity logger, or made specific through the installation of thread-specific logging on specific program behavior.

These two locations can be used by other programs of various types to access certain supplied system resources, such as RAM, DISK, BUS, or GRAPHICS. The programs that use these locations then are provided a set or unlimted amount of those resources.

Altering enforcement mechanisms to allocate system-resources can happen through the RING/ section and can be done through a .ini file or similar. See core_interface to learn more about extending system level functionality.

Since these locations link to the RING and the RING enforces what programs can and can't do, the RING should not be altered. The same would apply for distributing or redistributing these types of files as well - they aren't meant to be modified by the community, yet - they're meant to be elevated to a community standard that's acceptable for the desired program purposes. You define the program behavior and the logging verbosity yourself later, and there won't be a clear standard about what is the best way to do that. It'll be part art, part science.

An operator can determine how to tie thread-logging and activity logging into the RING properly - a place that won't change but provides enforcement of system resource allocation. To summarize, the RING will control various parts of ENTITYSCRIPT™ resource allocation contexts. These resource contexts are for accessing system resources within C.ORE™ and can be set on a limited or unlimited basis. The RING will also determine if those resources can carry anything towards the network for sharing or not and also determine if a OpenPackager™ program can have resoruces allocated to it or not. What people share on CORE.HOST™ is usually just an .entity file. But by participating in certain activity with CORE.HOST™ you also may generate a public record. Public records are either masked (private) or public by default.

All .entity files are stored according to the following conventions:

Collected software: additional items of interest that can be run as a system extension within the IPDVC™ by utilizing OpenPackager™.

All .entity files are the root context-map provider to a package. Each type of traditional system can be extended with these packages and made into an entity-extension systems. Systems that start out enabled for this type of system-behavior are called entity-centric systems. These entity-centric systems are sourced either locally or are made available globally. Data within these systems isn't shared by default, but the configurations of the systems can be made available for resuse to the community or additional computers that you operate.

The default handlers for these files are written in Python. Python helps the middle-layer make system calls as OpenPackager™ functions making runtime decisions. Python is used as the implementation layer for the underlying system services in OpenPackager™ too, but it doesn't make others rely on it or any specific language because any code can run through an extension enforced by OpenPackager™ and the appropriate EntityScript™ template. System services utilize the Access Identity Ring (AIR) platform can be used as an acceptable additional system constructs and extended to any user-space functionality after the fact.

The .ds data sheet DATA SLUG file type takes on comma separated cell usage in the most basic form, with constant quotes and headings enforced. Or these files takes a general 'blob' formats of any type but must then be hooked to an appropriate processing template in EntityScript™. Any format is supported with the appropriate parser being hooked to the blob.

There are index and key-based rows that can activate traditional column-based lookups for data. This data can be fed-to OpenPackager™ linked programs through the airEP™.

If you extend the base system lookup routines using core_gather the discovery and search for custom data-retrieval is also possible. You can use this to store a list of the packages that are in use and also use it for any other desired user-space lookup formats as well. A .entity file defines the title, the middle-layer package index headers for the corresponding .ds files, and any additional modifications or add-on file extensions.

That's it.

OPENPACKAGER™: Extensions

Right now, the only supported external extensions are:

Jupyter Notebook https://jupyter.org

The notebook should be accessed through a separate virtual environment and through a standardized https only approach. This requires some additional setup. Follow the following convention of placing the notebook system in a unique and separate ORE file elsewhere before you begin.

pandas https://pandas.pydata.org/

core_gather utilizes pandas when the operator chooses to do so. It makes things much more capable on the data science and data-framing end. Check out the project.

These are two examples, but any package can be utilized to increae the program functionality.

OpenPackager™ Entity Creator Questions

You can run the core_creator like this:

This will return an interactive prompt that can be used for .entity creation and setup functions. There is also a graphical interface feature, but the default is just a plain text adding system.

Entity Creator Questions:

Note*: If everything worked you'll see the following message, or something similar in structure:

The following .entity file was generated and now resides in *PATH*/DS7746875.entity

Now that this .entity exists, it is an index and meta-information portal to the rest of the system. It can be called by performing a lookup to the file using the lookup mechanism.

There are 5 starting types of Entities to create. These entity types are: Alias, Entity (Standard Context-index), Figments, Humans, and Locations. More can be defined too, but these are the intial 5.

All 5 of these types can either be a indexer, a contact, or a game. A game is an abstract-method that handles any defined-context. A game isn't like a sport match or casino, it's meant as an abstract method, like as in a 'game theory' implementation of any type with behavior that is understood through a control matrix-only. All the types have different extensible features that are attached to them depending on what is chosen during .entity creation. Some are static templates to provide static information, while others have time-based parts and can be used as part of an activity-based task.

The previous .entity file will be human and machine readable in C.ORE™ and provides a variety of meta-linking attributes based on the fields provided and the linked-files. Togther these form a structured entity-based DATA SLUG. A Data Slug can be used in an automation routine or reused later as a database-type of middlelayer..

Additional terms are used in the documentation (Partial-list: Full list with version 1.3)

Known Defense Schema

A file system where the position of the files and the duties they have remain known to the access-control program. This is done by designating the behavior of the program into various meta-functions and then using the allowed functionality to define to the access-control logic to system-resources. No system-resources are allocated directly.

System resources are allocated according to defined setup modules and security measures are in place to obscure these files from the view of any OpenPackaget™ user-space program.

Their byte size and inode position remains hidden to other system programs and the operator unless they're accessed though specific kernel-derived programs specific to making safe-lookups. This is similar to how the passord and shadow files work on Linux, but also implemented in a somewhat unique way.

A Known Defense Schema is built to be compliant with various authorities too. In some computing scenarios the required access logs can be generated and stored by default. If the IPDVC™ was in use at a health care organization, HIPAA would require certain information to remain private. You could put that information behind a hook and only have the location of that be revealed through an activity-que that in logged by default with certain parameters. There are also additional methods for providing ways of hiding data from unauthorized operators. In the event this data-trail needs to be revealed to an authority for compliance, it can easily be made available without needing to implement additional database voodoo.

Protected EntityScript™ words: Strings that require an escape of ###/(YOUR_ESCAPE_HERE)

These escapes can be used inside of a .entity file so that it can display machine-significant keys in human readable context locations while remaining compliant in text-mode. An example would be if you tried to use a protected word in the 'datascript_module' section it would throw a silent error, although no alert is made. Upon an automated check these errors can become discoverable and are able to be fixed by replacing the protected words with the replacement text escape strings.

These protected strings are not able to be used outside of the default positions in .entity files. They are only significant in specific locations. If they present a collision of protected strings in the protected key-section, a silent error is thrown and only discoverable upon a system-based check of each file. This is the intended behavior.

Publishing to CORE.HOST™

https://CORE.HOST can be published to as if it were a feed retrival mechanism. These feeds can then be propagated to networks that rely on the feed endpoint. If you have a VCNKEY™ that's valid, a authentication device check is completed without the users input. If you don't, authentication credentials will need to be provided as if it were an API. You can use your valid VCNKEY™ for generating contenxt according to a specific EntityScript™ defined block-storage context. Even a specific community that you create on CORE.HOST™ can be defined by EntityScript™. If that community relies on software, everyone will install it using OpenPackager™ therefor when they interact with the server all of their behavior only is generated from a containerized version that can provide default functionality. This enforces a specific type of data that's able to leave one machine and travel to the server or to a peer.

Although CORE.HOST™ is featured as an endpoint vetting system, many other types of block-storage systems may be accessed or used as an extended drop zone for your data - or a pickup zone for someone elses data. If someone else follows this exact convention for their endpoint and access-system using entities, there is no reason another server couldn't be used to do this as well.

Default stores of value can be made general through the following standardized exchange format:

*NOTE: These units have no defined value but adhere to a defined system of programmatic exchange.

The system has 5 properties: 1.) ItemVisualIdentity 2.) UnitName 3.) ByRarity 4.) ConversionMap 5.) CoreUnitDescription

In testing, the following table was defined and is accessible within core_transmitter as the example framework. It includes server-time based standardized unit distributions to members and the defined conversions of each unit.

Unit transfers are also possible, as is providing protection of locations based on available member-owned units.

Each unit-based mechanism for reclaiming unposted Unit transactions is theory-based for now, but there is a prototype that allows for the functioning of this concept. These scripts can be built on and altered to define units and values of your choice too if you're hosting a specific endpoing, but they're based on the overall unit value system. You define by Rarity, function, time, and purpose.

The default theory peg is "DGOLD-X" a mock digital store of value to use during testing.

---

IdentityItemVisual	UnitName	ByRarity	ConversionMap	CoreUnitDescription
	DGOLD-X-Bronze	Common	250,000 Distributed Daily, no base value - 1/40,000 a DGOLD-X	DGOLD-X-Bronze can be exchanged into the server each day to keep your network ad-free, permanently. You get Bronze each morning at 00.01 server time. If you don't exchange it or only exchange part of it to peers, the machine reclaims what's left at the end of every day and the DGOLD-X-Bronze goes into a collective server-holding account. When there is 400,000,000 DGOLD-X-Bronze there, it forks over the span of 24 hours known as 'THE AUDIT PERIOD' and at the end, 1 Diamond C.ORE™ is created and made available to the community according to a giveaway-game format. 1 Silver is worth 20,000 DGOLD-X-bronze.
	DGOLD-X-Silver	Uncommon, achieved	1/2 of a DGOLD-X	DGOLD-X-Silver units are used to aggregate tasks into value groups, and reward completed actions of various types. They're allotted once per day, 20,000 to be exact. They're only able to be spent on unlocking certain additional meta-structures within the program.
VIRTUAL	VirtualFigment™	Special Object (Periodic)	AWARDED FOR COMPLETING THE TUTORIAL - grants 1 VirtualFigment™ struct-entity that can be used for publishing content to peers.	You have to earn the right to post by completing and continuing to understand a community guidelines rule-set.
	DGOLD-X	Rare: Upgraded to -> 'HIGH EXCHANGE' type	Earned through various defined behavior	This is the basic system-crypt-peg within C.ORE™. All other units operate based off of it.
	Diamond C.ORE™	MINTED: VERY RARE	Prestige	When the CommunityCollection reaches 400,000,000 bronze, 1 Diamond C.ORE™ is created and made available to the community. A Diamond C.ORE™ can be used to unlock general chat structures and various long term meta-methods. No one can speak in general until they've discovered at least 1 Diamond C.ORE™. MAX 1 per day. Anyone who has discovered a Diamond CORE™ may also give away an established set of chat invitations monthly afterwards to peers.
	Gem C.ORE™	GEM	Special Object: Awarded	Gems are awarded to you for community building and assistance. They're based on internal nominations. They hold no value, but are required to be above rank 30 in the system. Above rank 30 provides additional meta-structures.
	Mystery C.ORE™	Unseen	Estimated Exchange: 4,000 DGOLD-X	Somewhere around the year 2020, a machine known as C.ORE™ came online and began indexing information differently than before. The mystery core is still unknown but it's rumored to have various meta-structuring properties granted with the discovery of this type. In the archives it simply states - "The mystery C.ORE™ was best left undocumented, and better left discovered".

When any resource is made available to exchange types, it's also recorded on three sub-tables. Here is an example of what each of the 3 sub-tables look like.

1.) Value-table, general:

2.) Public Domains accepting ORE™:

3.) Private Domains accepting ORE™:

Together, this type of system creates value exchange options in C.ORE™ utilzing CORE.HOST™ or a system like it. 'ORE' is the default exchange type base-value, although it is valueless as a currency. It does hold value as a store of activity-based time-value. ORE stands for Operations Resource Enclave™ and ORE™ has significant properties in EntityScript™. ORE™ provides a way to exchange meta-information of various types utilizing this base-format.

The following set of publishing tools makes up the entirety of this posting, editing, access-control, and data-removal system. core_url and core_transmitter work together to format these requests on the fly, including validation according to the below format details.

Block device ledger: Standard .entity retrieval mechanism from an ordered and compliant index

'index-slug' is setup to also take keys. Keys are created by others in C.ORE™ or adhere to a prebuilt kind. For instance, 'L:' at the beginning of index-slug declares a readable and compliant list location.

'index-slug' can also be either openly named, or masked through a special property called 'MASKED ENTITY'. When a masked-entity is created the default master-copy location is 'MASKED RECORD', while the default 'record-location' value will be set to 'UNAVAILABLE RECORD'.

Each of these hidden record types aren't set up to follow any specific position in this example, but a position does exist. While an access-point is live, three distinct locations become available once activated. The first is a 'index-slug' location, storing the resource location of the LINKED_OBJECT. The second linked-to position is the 'master-copy'. A master-copy is a direct link to the stored location on a compliant block-exchange structure. Lastly, the 'record-location' provides a unified resource point that stores meta-data about the linked-entity.

Together, these actions store the meta-information on a ledger and become an available resource that can evolve without human input.

FinalLedger

With these ledger types now available, records can be determined 'ONLINE' or 'OFF' making them either discoverable to those with resource access or they will not be available if they're 'OFF'. Next, the default record values of each entry will generate into a posted and compliant block-storage structure according to this format. Here is a look at the default record-store.

Example:

C.ORE™ Record - DS3927107

FinalIndex: General mass-access location

A final index is now made available. Here is an entire FinalIndex example.

C.ORE™ - FinalIndex

To summarize, OpenPackager™ gives the operator various forms of open information exchange formats to utilize for various tasks, from packaging to meta-information, to transaction unit-protected methods.

To see an extended list of special locations in C.ORE™, click HERE

Locations

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

.CORE/DOCUMENTATION/

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.

ALLOWED_LANGUAGE/*path_to_allowed_language*/

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.

PROGRESS_FILESYSTEM/

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.

RING/

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.

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

System Audits

Audit Tags

System Audits can be as simple or custom as you need. They can replace the need for traditional introspection tools if designed into your extensions properly.

A Use this tag when logging a generic audit block

E Use this tag when logging an `event` block as described in the standard EntityScript™ library

S Use this tag when logging a `search` block

P Use this tag when logging and identifying a parsed behavior

K Use this tag when logging and identifying a new `main` or `active` function call

System Audits: Extended file auto-checks

The main .CORE/ directory performs very little. It does however perform audit_home checks. Essentially, it looks for a status queue. If the queue exists the system starts and stays running. If it doesn't exist it can start but won't run.

.audit_home/STATUS.X will tell the operator and the machine upon startup that the system and all tracked/known files from the last session are still there and in working order. The goal is to take anything that makes this hit to '.ERROR' and to isolate it for later processing.

This folder will produce the following file if everything is okay:

produce in-> .CORE/

.audit_home/STATUS.OKAY

If there was a syncing error or startup problem, the following will be true.

.CORE/

.audit_home/STATUS.ERROR

You can check out more about generating manual scripting-based processes and extending system audits with packages available through the implementation language: Scripting

Scripting

C.ORE™ Standard linked-Library and Scripts can be utilized in parts or meta-structures. Parts are released in a rolling-release model, while meta-structures can be swapped out entirely with your builds or those from the community.

All of these files-types are able to be interacted with utilizing EntityScript™ and the initial version of the program released in 2020 had very basic uses attached. Even so, the program is functional. Since, the versions have been extended and tightened even more and the version 2.0 release is consumer-grade.

Each open source file will be available here soon too. Python 3.8 was used as the implementation language for version 1 and the full package has been tested on various systems capable of running the language.

Note* - This section does not include the needed folder structure, log variables, or initializer scripts. The folder structure eventually will be available to download from CORE.HOST: Download Portal. The intializers, log variable startup scripts, and other items will be able to be downloaded from https://core.host/configurations/ by the end of the 2023. Enterprise customers will have tailored access to each of the required parts to run the system in the latest branch. Until more people are using EntityScript™ those customers will get exclusive support. The technology that's being presented is for general-purpose computing, but enterprise customers can benefit from more specific services.

Property Table

The default script is named the same thing as the parent first-position meta-structure, CORE.

.CORE/CORE is the default script start position and allows you to work with core.es and CONSTRUCTED_core.es from the start. The reason these containers exist in the first place is to store on the fly information in a log specific format that's intended for archiving activity. All of the other scripts don't rely on this script but are able to work with it when storing structured-data on disk in long-term archives. These .es files can be branched into a traditional database if that's what you want/need. We don't want to write any kind of data to disk that hasn't been processed into a storage format that's defined and moved out of temporary containers. We also will want access to the underlying sub-system itself but don't want to call to it directly without some convention or reasoning in mind beforehand. The default script doesn't provide system-level functions at setup, but if you need them in various situations the best place to store their linkage would be in the default script. C.ORE™ as a grouping of scripts is a interface extension methodology that's not meant to rely on the rest of the program at all. C.ORE™ has many parts that can be setup to access system-linked resources running here - or primarily through a middlelayer. There needed to be one point in the system where links between the host and the software running in C.ORE™ could be made. The default script C.ORE™ is where that happens. It can be extedned as needed.

There are also several other areas to work with too. Here is a list:

Outside of the standard configurations, program behavior, and scripting locations, new ‘pools’ of information can be localized or extended through the use of meta-specific ‘ResourcePool’ modules. These modules can occur in any meta-structure and are used to localize general program specific information into a meta-related local context.

Additionally, if you choose to provide top-level node support you can customize the initial initializers. You're able to set or extend default variables, or install root level customizations.

These files all can all be modified, extended, or for the most part - eliminated entirely at startup if you choose to replace them with other functions. Use EntityScript™ in different ways according to your needs. To see more about the startup process and interacting with these parts click HERE

Startup

When you turn on C.ORE™ EntityScript™ files can be read at determined intervals. These intervals can be 'packed' with added functionality.

The following steps are executed on behalf of the operator upon startup and can be modified as needed. These steps provide 1 stateful machine for use. You can continue to startup new machines until a systems resources are exhausted, meaning more than one machine-state can be running at any time. You can also limit the amount allowed at run-time to 1. C.ORE™ itself doesn't launch async processes, but it can provide an async sub-system at any of the steps below. Each step is a significant software process that drives specific machine outcomes utilizing additional EntityScript™ templates.

These are the following documented steps in the startup process:

With graphics 1 C.ORE™ instance utilizing EntityScript™ runs under 1GB of ram and provides most functions required to operate a personal computer without any programs besides a window-manager and kernel, plus the implementation language and what's required to run it (Python). Learn more about what happens once EntityScript™ virtualizes your instance by learning about airEP™ HERE

airEP™

C.ORE™: airEP™ File-system (Access Identity Ring Entertainment Platform: airEP™) is an entertainment for the future of self-generated online content and distributing it to others doing the same. Everything is managed by keys and access of content is tracked in a transparent way.

airEP™ is enabled by something called the IPDVC™ (Internal Processing, Deployment, vetting-system Computer

Here is some more detail about the parts of the IPDVC™:

ACCESS/

When the Ring gets invoked by the handler inside of the Identity folder, this silo becomes a read only setup-slug. This folder controls I/O read/write access to your system while it interacts with C.ORE™ and while its being controlled by any stateful object also using Access at the same time. All system bindings happen through Access.

The Ring is made up of 3 unique parts and no more, and they're all carried in some form of statefulness by Access. These two parts work together to handle stateful machine definitions. These same definitions help keep your instance secure according to various preset operator needs. If you'd like to challenge convention, please save your passions for the Identity section which focuses on expression.

Access, like Ring are static systems inside of C.ORE™, similar to a kernel, except they set no machine interfaces by themselves. They only exist in Memory once state is achieved.

This section is meant to mimic the minimal code architecture of a micro-kernel, but it is mapped and activated differently because there are more parts. The convention is simply to achieve statefulness and control of the operator instance/user-space, not to provide extended peripherals or achieve low level things like power supply and CPU definitions. All of those things are assumed. So this is operating above that layer. The main advantage of these mock-virtual kernels like we have here is their small size and enforcement potential for various items in user-space. You could define a tight "no more and no less" system with a few hours of thinking. All extensions happen in OpenPackager™, which also interacts with Ring and Access to determine credential and ownership values for various operating items. It mainly attempts to confirm something in memory is as intended before committing more details to disk. Access, Ring, and what runs with them - OpenPackager™ exist mostly in non-perm or higher system routines. Linkage to OpenPackager™ happens almost entirely in memory and when it manages a new program or routine, it remains aware of the amount of system resources that are currently available.

The RING is no different once settings are read on startup. Mostly the following statement will hold true: once things are setup, the RING can scale an instance on one machine to many machines safer than a human could. EntityScript™ deals with multiple-machine models, so the RING not changing but providing scaled modes through EntityScript™ templates was required. Some of the modules that are branched into by the RING are set into an immutable file-type that's enforced by the kernel itself.

Separate instances of C.ORE™ can propagate through an automatic fabric provided that checks read-only values.

There isn't meant to be any sort of changes to the ACCESS/ structure either, and when a change occurs, the program state changes, which requires a new instance to be generated entirely. Once the entity is "up", the pre-defined values do not change and if they do, that is a New Entity™. That's why the ACCESS section works on startup only to encode the RING with instance specific variables that define all of these decisions that get made by C.ORE™ using EntityScript™ templates. This includes interfacing with the system configurations necessary to make immutable instances happen, log them when read,, and work with the other functioning parts of the program to give a type-check safe interface to the user.

ACCESS - like RING, exists with explicitly defined sets of directions in a .entity file. These files are only readable by certain program types. They pull from a Data Slug datasheet ( .ds ) file elsewhere that can contain any type of data. These slugs are either privately owned and locally 'slugged' or publicly available to anyone at https://CORE.HOST/community/ through the CORE.HOST™ API.

The C.ORE™ program sits inside of your home directory by default. If you're just starting it for the first time, you can put it there and do these three steps

1. Build
2. Setup the Filter
3. Add Programs (no added program-extensions are provided in version 1)

ACCESS naturally gets to interface with your defined data too when certain security data is verified by the RING. ACCESS always does this interactions indirectly through the values provided by what RING generates. This is where we will pick up more with next time.

Additional Features: ACCESS

ACTIVE QUALIFIERS

Active qualifiers allow you to narrow down a request to the program by providing a search-interface with EntityScript™ parameters provided. These qualifiers can become infinate in scope and are only limited by available resources.

EntityScript™ is a syntax lookup engine too. It operates in a complex manner but presents a simple interface to the operator. The "ACTIVE QUALIFIER" terminology specifies the responsiveness of this lookup system which operates in almost real-time. If we submit the search form, the Access and Ring sections are invoked as a pairing then the taken string input from the box is translated by other sub-systems which already hold qualified results. If the filter text is in the queue, it'll then be returned. That's the most basic method. It can get much more complex, but we won't get there during this explanation version. We're giving you the opportunity to narrow down information more quickly soon and we'll have it documented entirely by version 2.0.

The C.ORE™ (Cognitive Operations Resource Enclave™) system facilitates the in memory safety checking for this to functionality on the fly and the retrieve data operation onto disk can be provided to the program safely. This is meant to occur on a localhost or over the network.

QUALIFIERS: General

All qualifiers are created in a .entity/.ds relationship defined on your system. Sometimes a .ds file is empty, other times it has CSV data, or JSON. It can even have data of an unknown type.

This relationship works directly on top of your system without headaches and EntityScript™ determines the data-type on the fly. Some data-types can perform certain roles while others can't. When an OpenPackager™ instance wants to be added to the "RING" location which has Access, the package will need to have a .linker or program defined privileges already enforced through a pre-built EntityScript™ template.

You can set this all up in a .entity file linking back to the .linker file which is gone over briefly in a previous page.

We never make calls to protected slugs by calling the .ds file directly. We want to do a linker lookup first, verify the integrity of that relationship, and then call the "built" file based off of it's own protected lookup system and permission specifications.

More on preparing .ds files:

1. Get the file into line-by-line format: i.e. all lines represent one additional meta-entity of data with various attributes defined elsewhere in a .entity file. If this structure can't be verified and an alternative structure isn't provided, the data-type will be considered 'raw'.
2. Make sure the file is UTF-8.
- ODS, XML, and other files can be used, but we want this in a Data Slug datasheet file in text-mode first
- The most proficient and preview structure is essentially a CSV but with a modified header and cell type that have an enforced encoding. More complex files need specific .entity templates, but they can easily be defined when they're needed either by you or by the community. The linked-file is 'built' entirely from the provided context controls made available by EntityScript™. When you share these 'built' contexts, they rely on a block activation model that works within CORE.HOST™ for sharing.
3. When the data is finished being prepared in line format, save as a CSV file (This has been found easiest if no other tools are available or your system isn't teched out. You could save it directly as a .ds file too.
- If you're in a CSV type editor, you can do this:
- Select Save As
- add options
- Surround everything in quotes
- Format type should be set to UTF-8 text version
4. Open the CSV in your editor
5. Create a .DS empty shell in UTF-8. This file can receive a dump from the CSV you have open, or simply rename the file .ds if your system is formatted correctly to handle the raw dump.
- If dumping the data from the CSV into the DS file, copy and paste and then save the next file.
7. Exit
8. Verify the file using core_gather.test()
- Pandas can be use as an extension to read the file as a CSV type even though the file is type-enforced and double-quoted by default to conform to EntityScript™ and also make it backwards compatible with other programs. The file will be ready to read/write to .ds/.entity systems as well.

More Examples of cleaning data from complex types into line format. Sometimes you'll have to convert random file types too.

A QUALIFIERS.entity file can be created to your own specs to help you achieve this for a variety of known data cleaning methods. There will be more meta details for the format here to look into soon too, but to summarize: To become accessible to the qualifiers area, you'll need to add data to the corresponding .ds holding file and then verify it with the Access Ring. This makes sure that .entity/.ds files can only be read while a system is on and by the correct user-space parties.

Each entry in the QUALIFIERS.entity file would be some known routine for taking in and ingesting data. The goal isn't to need them, but they're meant to help.

In this case, the QUALIFIERS.ds file can act as a mask for even deeper rooted DS files containing specific program logic or nested permission management.

Example:

This is some mock up basic of how you could branch routines into more processes for whatever needed reason.

ACTIVE QUALIFIERS Also work by typing in various Keys. All the Keys will eventually be up here. ESX is one, ESV another.

In this case, ES is a designated precursor that activates a blanket matching search in applications that have this enabled such as BrowseMeh™. Anyway, the main point is - it's all managed by Access/Ring. Then there is the Identity!

IDENTITY/

All static assets utilized by C.ORE™ are displayed through a similar linkage described above. You can use IDENTITY/ to separate and optimize them. You'll be able to keep things like instance photos, 3D assets, various digital arts, and other advertisements here if you're serving them to guests as a host. It's like a basic publishing review and organizing mechanism for YOUR stuff only that you're then able to share. Other peoples stuff goes in the FILTER/

Identity Overview:

TYPE: ASSET

Anything that's run by a program in C.ORE™ is 'ACCESSED' and 'RUN' in .CORE/OPENPACKAGER/

This includes:

DIGITAL ASSETS, PROCESSES, AGREEMENTS, TEMPLATES, BACKGROUND INFORMATION, DEFINITIONS, CONFIGURATIONS, MODELS, FORMS, and ROUTINES

SECURITY: Authorized Resources Only: Required clearance: 1FA

RULES:

1. You are allowed to participate in the studies or templates that you have been authorized to by specific asset owners owners only
2. You agree to purge all non relevant materials or unowned assets from the machine during manual machine filtering
3. You agree to make available your findings and datasets with relevant authorized persons upon request from each lawful activity
4. You agree to use only the materials in this section that are licensed properly according to the "New Entity Operations Licensing Handbook"
5. Do not corrupt source files - always make a branch and label it as a derivative work -
- - BranchName+\
- - VERSION_CODE+\
- -_VERSION
Example first branch first version: GreatestProgram_1_A 6. A table of last resort should be created and maintained for each file and searched for there. The framework provides ways to do this properly. Manual lookups are discouraged. Consult additional readings for the correct lookup methodologies moving forward

RING

The location used to setup various system access commands. Some examples would be adding and deleting users, turning off base-features, and doing other policy enforcement. That's RING in a nutshell.

The RING needs:
1.) User-supplied Information: The Ring is the interface-access module, but it doesn't function without your initial startup commands turning it on.
- Each RING part is toggle-based through a front end. This runs in core_FRONTEND.py. This helps you manipulate various interface options and system functions without installing risky dependencies.

2.) BuildSpec - The BuildSpec is a status oriented directory structure meant to read the status of your machine state and provide contextual support based on that. This helps the operator control system and graphical functions without messing with anything near the Kernel. This establishes more or less a basic set of definitions simulating emulator devices.

BuildSpec: Additional Details

This can include documentation for programming languages and additional support materials intended for quick recall/fact access later on.
The Audit Home directory or "AUDIT_HOME" either prints STATUS.OKAY, or STATUS.FAULT. STATUS.FAULT occurs when the internet retrieval data frame can't connect to the defined 'Universe meta-storage' existing on the network. This can be because of a write access error or a misdirected extension, but it usually just means your offline.
The Documentation section will have the base/standardized documentation for any software running within the machine in HTML form.
The Hardware section stores .so compiled files that can talk directly to your hardware device and handle devices. These devices can be defined within the OPENPACKAGER/ folder. You'll find more information in the documentation on that there soon.
The IPDVC is the Internal Processing, Deployment, Vetting-System Computer contains the /tmp directory structure defined in the IPDVC.entity file and destroys itself when the machine state is STATE.OFF. STATE.ON can only occur if the IPDVC™ contains a bin with the proper .so file extension to start the instance on the operating system. The Learning section isn't active and was removed from early versions. A list of documents intended to help operate the machine - that was the vision. But it really only made sense as an item inside of FILTER/ unless you could find a way to eliminate the need for other peoples information/data to make it useful.
The Operations section contains prebuilt or stored code-snippets or operating syntax that can be accessed through the machines 'emulator-interface' while the state is 'STATE.ON'
The Packages section of the Ring contains any desired package according to a semi-controlled format. These are managed through OpenPackager™ in the corehost or external folder. Upon the state of the machine turning to STATUS.ON, the packages folder will populate with sym-links through a temporary ln - assignment. This will be unassigned when the status of the machine is STATE.OFF
The Setup Box section gives you a way to store prebuilt content and other moderation rule sets. You can then force the machine to comply with those rules. This way you keep yourself clean from potential licensing and usage headaches.

C.ORE™ operates off of a extensible key-based system too. Check out some of the current lookup Keys