GRAPHIC: New Entity Operations™ Alpha Logo

EntityScript



EntityScript™ Overview



Release Program Title: EntityScript™

Copyright: New Entity Operations Inc.


Purpose: Add a standardized human data-to-machine software interface to a system of your choice with EntityScript™. Interact with CORE.HOST™ related programs to improve digital work-life balance and retain control over personal data.

Extensions: https://www.core.host/


Background:

EntityScript™ provides a human-oriented data-to-machine software interface to anyone that uses a computer. EntityScript™ can also be used as a physical idea-templating language if a computer isn't available to the end-user. Operators working on a concept system called C.ORE™ (COGNITIVE ORE™) can also gernate and exchange their pre-built EntityScript™ templates. The goal of the project is to make any data that someone has in their possession a structured process and to have that data reside within an exact recall-related methdology.

Since EntityScript™ is a defined structural authority to a human-to-machine interaction, processing system-level data-storage is simple and safer than doing so in an adhoc way. EntityScript™ is powerful because extensions are able to be used that can augment the scope of each interaction to a nearly limitless set of possibilities. Overall, this user-space and system control methodology has to do with accessing and processing personal data of various types and how the computer interacts with these types later on. All of this is defined in a standard that can be implemented or extended by the end-user. These standard-types usually are defined and processed using various techniques made available by EntityScript™ but can also be designed and defined by any operator.


Implemented techniques for procesing data are part art, part science. At the end of the line, each component is ultimately processed by a kernel program of some sort. This changes depending on the system that's being used, but EntityScript™ never changes. Systems take on various system-dependent implementation languages to handle scripting and processing, but EntityScript™ can always access those methods using an exact extension specification.

A control center for keeping your human-oriented data structured in a machine-like format has some benefits. To start, 1 access control program operating in this methodology allows you to quickly profile data that is randomly sourced and eliminate that type. All types should eventually be defined and types that are undefined are easy to find and either destroy, or store accordingly.

Since EntityScript™ sits ontop of a kernel, the templates act as general-purpose access control controls for the system.

Each client-hosted system that uses EntityScript™ makes and provides ways to extend that systems functionality. The system can expand into any functionality and operate in a "loose" mode, or it can be operated in a "tight" mode and be operated in a very controlled way. EntityScriptp™ was designed to accomodate each mode of operations.

C.ORE™ (Cognitive Operations Resource Enclave™) is a program that was built to gradually unleash the full potential of EntityScript™ by first starting with basic functionality that took advantage of basic features of the language. Gradually, C.ORE™ is being improved to process and interact with machines in even more advanced ways. Humans interact with C.ORE™ through an interface called a memoryform™. This is an application specific to C.ORE™ and the purpose to to tie kernel-space to user-space that houses human-specific data. User-space can be expanded to use any application that runs on the operating system that's being used. This applies to Linux, FreeBSD, Windows, or MacOS.

The user-space that's used a human utilizing EntityScript™ creates an audit-driven by default type-check style system-UI. This allows any program that is generating visual output, to have an exact set of defined abilities while accessing kernel-level functionality.


Building into C.ORE™

C.ORE™ is a program that has been designed to accomodate and handle many different operations on the machine-level. Each of these methods are gradually being improved to include the best possible version of each type of interaction that is provided. That is why C.ORE™ was designed to exist both in parts and in Meta-structures. Parts can be improved independently, while meta-structures can be extended by operators in custom ways. EntityScript™ knows how to best interact with both of these kinds of functions and provides an exact way of handling iteractions between the end-user and the system because of this.

EntityScript™ gives end-users of these part based Meta-structure machines ways to interact and control them in a way that is fully transparent and open by default. EntityScript™ is not designed to limit any system operator and puts control in their hands to build a semantic personal data-blueprint.

Interface programs like the one presented in C.ORE™ version 1, although rough, proves a general set of concepts about the system. As each version is developed and released, new and improved parts will become available. The prototype system wasn't meant to be functional, although the system does work.

As it stands, C.ORE™ can interact with standardized windowing system in a generic way. Other types of custom machine-to-visual space implementations can be integrated by using additional graphics sub-systems such as Mesa, OpenGL, CUDA, and more. As long as you can get to user space and run Python 3.10+, you'll be able to run the semantic control system to enable this behavior.

The default C.ORE™ tool-chain is meant to be implemented in a minimal-first mode that can be modified by someone that knows Python. The minimal mode is text based by default and all the functionality can be ran in a terminal emulator. "Extended" mode encludes graphical components but will require a graphics subsystem to actually process the graphical I/O.


The future of Computing is Human

For many years the Interface of a computer has been a mystery because of how hard it is to track what happens with each type of input interaction. With EntityScript™ we can handle many of these mysteries and give the end-user a way to automate parts of the system in an observable way that usually would not be able to be accessed. Many types of tasks can be accessed with more transparency using EntityScript™ and the ones that can't should have a trusted low-level library handling their functionality, such as the kernel.

We decided to virtualize the interface by default so that you could have one program to handle all input related tasks without needing access to kernel-mode interactions. Those interactions are handled by kernel-mode hooks.

Kernel-mode hooks are safer than accessing the kernel directly. This methodology also allows for safer machine-rsource allocation in situations that require the distribution of a finite amount of host resources to each new process. EntityScript™ sits on top of these processes to help modulate each resource intensive process and while also keeping them observable in at runtime. This is beneficial in various data-sensitive situations.

EntityScript™, eliminates the need for host-machine dependency management. The goal is to have a kernel and an interface, that's it. The interface that is implemented through EntityScript™ control templates and using C.ORE™ methodology gives you one tool to cut out multiple other packages in the middle-layer of your personal computing stack. The operator has modules that can be enabled in loose-mode following conventions to extensions made available by EntityScript™. C.ORE™ acts as an interface for actually retrieving and processing each type of new package.

Because the future of computing is human-first - it was essential a program and templating language was designed to cut down on shadow processes happening on the end-users machine.

Auditing these routines and packages easily was also essential in the presented format. A way to create your own routines is available using a default logging and audit framework that is quite robust when applied appropriately. There also needed to be a standardized portal and access point to a community making available New Entities™. This is why CORE.HOST™ was developed and the site is also gradually being improved to accomodate the goals of this project.

When the operator creates a convention on CORE.HOST™ according to the EntityScript™ and C.ORE™ specifications, they will be able to share, find additional methods, and install structures made available by others easily. This was an essential part of making EntityScript™ work as intended at scale.


Purposes of C.ORE™ and CORE.HOST™

The C.ORE™ program helps you organize large quantities of both structured and raw data types of an unknown or undefined origin. This also allows for evaluating past data-systems to clean up and structure what's inside of them. After you use the EntityScript™ approach to doing this, your past systems are correctly 'metatized' for future access. Anything that couldn't be defined should be destroyed and never thought of again because it represents wasted potential of future resources - both time-based for the human, and computation-based for the machine.

These new 'meta' attributes can easily be recalled at a later date according to setup routines that enable automation of retrieval or storage of new tasks of that type. In EntityScript™, you'll do a lot of routine building with community defined formats and extensions hosted on the CORE.HOST™ platform. These formats and extensions can be utilized in both static and automated scripts that can be type-check enforced by EntityScript™. Scripts are made available by categories and by rating, although the rating system is only just being designed now. Categories allow you to find routines for your own data-types and implement them quickly without having to build a custom EntityScript™ template.

The community website is setup to help you build, enforce, and discover system-linked data later, by profile and then storing the data you already have in your possession. Sometimes you'll use the tooling to build your own entities, or connect your designed formats into various legacy data-structures to clean them up. In this scenario "raw" or unstructured data is a type of data-structure. EntityScript™ is loosely defined yet there are exact conventions to creating new behavior. Raw data by the nature of what is represents should be worked into a defined format and C.ORE™ helps you do that safely with the computers available resources. Sometimes raw data can harm your machine and we want to cut down on the possiblity of that happening.

All of the rules provided by these EntityScript™ drafts are clearly defined and exact in implementation. Although this overview is very complex, the tools will not be complex and are very clearly presented to the operator.

Because EntityScript™ is meant to be general-use, any person needs an interface to assist in creating them quickly in a manual way. The initial interface that's provided presents a generic alpha version of this idea.

Automated tools that are provided to process the data and retrieve EntityScript™ templates using keys. This is the next frontier of enabling and extending "Operator driven computing" into shared-community derived structures.

This is a new type of computing-methodology reduces base functionality and adds in more abilities to build original or community generated routines using simple interfaces. That is the essence of EntityScript™. The original goal of this project was to develop 1 and only 1 system interface to sit on top of any kernel as long as it had the basic supported language able to run. Today, that supported implementation language is Python (www.python.org). It was chosen as the build and extension language for many reasons, but mainly because of how widely supported it has become. Python is a strong language with nearly unlimited scope. That is why it we are going to continue using it to develop EntityScript™, C.ORE™, and CORE.HOST™ in the future.

You don't need to know the implementation language to use EntityScript™. You can also use the language you prefer, such as rust, Ruby, C++, C, and even more. However, if you do use another language, you're using the program in loose mode and the behavior is considered a mod of the original specified system functionality. This does allow you to operate your system in ways that that other users couldn't without following in your footsteps.

The implementation language may always change in the future, but the principles needed to endure over a variety of strict criteria. That's what made Python the best initial choice. A small version of everything runs in C too, but that build is experimental and there isn't any intent to make that version public.

Data that's structured, observable, and trackable in a variety of modern formats from text-search to voice-control became essential to meet the demands of the future generation. EntityScript™ supports all of these next-gen formats through extensions. Also, a high degree of customization was essential as well, because new formats are never the same. EntityScript™ is an attempt to summarize all of these essential parts into one interchangeable middle-layer resource. The goal is to allow you do do anything that you need with it as long as you follow the presented conventions.

The featured library, scripts, and information featured here help assist humans in defining exact data-formats that utilize the "know your machine" philosophy. This extends into you file systems and how file-data is stored too. These "known always" formats can be of both traditional or experimental in practice, but EntityScript™ gives you a way of defining how they are scoped in your machine. Each structure has to have certain elements in place to be consider valid, but these are clearly defined. A valid EntityScript™ file will be both able to be run by core_gather and also become discoverable within the C.ORE™ application.


Secondary Purpose: C.ORE™ can be extended to replace most basic system functions through a virtualized I/O interface. This interface maps and protects personal information on stateful computer systems.


How to use:

A C.ORE™ operator can collect information from many public or private sources in any format they would like. Once it's collected, if the information is extensible through an EntityScript™ template or previously through a compliant structure such as JSON, CSV, or XML - a New Entity File (or .entity file) can be generated. Once this file is generated future data is stored accordingly. This format makes the file and the data in the file re-discoverable to your system (and you) later. If there is no previous definition, a new definition can be implemented and enforced by the underlying code by creating a new .entity file manually and testing the data-relationship integrity of the template yourself. This means that you'll easily be able to utilize a variety of meta-structures that you define for any task that you wish to accomplish. This type of information recall also can be implemented by various predefined data-points made available by the program and community.

The community is being constructed to help people reuse data points as blueprints for future processing as much as possible. The CORE.HOST™ site also gives you a HQ for the network that you've defined.

Ideally, nothing on a HOST machine would ever be able to not be instantly recalled, mapped, edited, or removed by another using the same process - the difference is that they don't have your data or ways to access it. There is an experimental feature under development that allows you to share your exact data with another user through CORE.HOST™. That goes for packages, scripts, components, templates, etc.

The only thing that should ever need to exist in more than one location for two or more individuals to process the same type of data is the existence of two or more EntityScript™ templates that have the same structure. The underlying data is not the same. The way the template interacts with the underlying kernel code and the program itself does not change. This is entirely open source. So, using EntityScript™ will require making those two environments (kernel and data) as separate as possible. A good way to do that is by starting with a fresh distribution installation of your choice operating system, and gradually bringing in your data but only into structures that are pre-defined.

Information sources include media and static content from a variety of legacy and modern file formats. These formats are made up of structures holding containers such as a file system of an exact type. Even structures that are anti-patterns of various kinds through encryption can be made to be discoverable as well. With C.ORE™ you're able to replace the need for any third party or closed source tools to get these interface options available on your machine - EntityScript™ templates and layering them together will activate that data. To make the data summary/recall processes complete, you can use EntityScript™ discovery using core_gather. This originally was known internally as the IPDVC™ (Internal Processing and Deployment, Vetting-system, and Creator). The aim was to allow software to gather various data-types to conform to an origin point access-control schema for any discovered data-structure. This ends up being enforced by lower-level kernel code when it's processed within your machine, but while it's in discovery mode, it sits inside a virtual container of the program itself. This process unfolds with a similar tag based approach and can be extended with EntityScript™. Extending EntityScript™ enables internal tracking and policy-based enforcement of various methodologies on the system. You're able to take past information types as inputs from various structures (currently there are 218 finalized) and restructure them into a variety of both trackable and loosely defined (yet exact in methodology/form) recall structures.

Recall structures will be available at https://CORE.HOST/entity/ and are either provided by the system or generated and distributed by the community.


Some closing introduction thoughts:

When information goes into C.ORE™ and is being enforced with EntityScript™, it can be configured to be logged and later accessed in various ways too. These information types can then be stored locally, in local system groups, or publicly on external endpoints. Many of these types are goverened by simple conifguration containers and published to a central repository on https://CORE.HOST/configurations/. In short, you're creating the context and then defining how that information is recalled later. It's then enforced by a control program that takes a configuration file and operates through a schema provided by EntityScript™.

A schema makes it available as a category and a category makes it disverable. The information made available by a category can be recalled later according to various methods, either ad-hoc or strictly tracked by your machine through logging and profiling the related usage. Further, for important user-space methods and security enforcement, an entire alert tagging and tracking system also exists within the program to help with future event tracing that can be used by EntityScript™ to generate reports.

In summary, EntityScript™ helps you with user-space auditing and key-based system functionality.

Any information you come up with at some point in the future should have an equal and opposite .entity file to store that information with safely and with the understanding of accessibility-first functionality for the future.

In C.ORE™ you're able to sort and inspect these interactions deeply and with various intents. The information that ends up coming in and being stored on your virtual interface can adhere to both on prem or cloud-first models. EntityScript™ is built to interact with both.

Lastly, the resulting .entity/.ds format simply called "EntityScript to Data Sheet" can be stored, customized, and accessed at a later time too according to a set of structured yet flexible storage of last resort methods. These methods can be published without revealing format-specific information using various templating techniques provided by the program.

Omission Schedule

* at the start of a line means a single release related detail will follow. No * at the end of the line or area means it's not a site que yielding any specific information other than what's described. There are more expansive details, such as 'RUN/START COMMAND COMMING IN Version X'. There are two others: 'DETAILS coming Version X' to say that the details of what is being talked about in the omitted text will be there in a specific Version mentioned or not at all depending on what's decided, and 'commands coming with Version X' to signify general common types of omissions related to in use commands. These commands are covered more next.

* at the start of an area followed by a * yielding one of the conventions from above will show that those omissions mean what was just discussed. This omissions only occur when the whole omission area matches the convention. In most instances an omission is there because the status of that part in the next Version is still in question or in the process of changing.

*** anywhere means something has been omitted for an unspecified reason.

***** anywhere means something has been partially removed for an unspecified reason.


Summary of Goals: Take any legacy file format that contains information and convert it into a dynamic and instantly accessible data portal through the EntityScript™ file-recall and operations format. Provide functional computer services with software.


To learn more about the .entity/.ds format, proceed to the next section .entity/.ds Lookups

To read more about the technical specifications of the system, see the section Technical Specifications and Extended Library Features.