EntityScript

Draft 1.01:
Index







Sections: Status -> Approved

1.) EntityScript™ Overview - Overview of the project

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

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

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

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

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

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

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

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

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

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

12.) How-to: Additional Notes

13.) Moderation: Basic moderation principles

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

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

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

Alerts and Logging in C.ORE™



Use the built-in user-space audit framework. 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 as they occur and stores defined outcomes when they occur. These outcomes are segmented into silos when logged. Each logged silo works based off of user-defined types of both preset and self-created origin.

At any given time while the program is "up" there is one main process running. There is also a personal instance server that survives base program termination and runs as a separate process. Each running thread is able to process data as if they were sub-states and aren't bound to each other at all. 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. 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 sort. 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 they 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 try to implement your own logging routines. It's better to follow the provided framework. Follow the set computing-transaction methodology available in the preset methods.

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 enforcement criteria. These time schedules can take "Alerts". All "Alerts" are the way that common data types flow into .es files, even when they aren't explicitly logs them self.

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 of files occurs. By default, your logging behavior can be branched into there and can serve as a portal web server logging, system logging, firewall logging, and other things. Only data that has already been processed and archived according to an exact format should remain there after these automation routines occur. 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. This helps the operator get accurate and timely insights and also helps keep the system current.


The goal here 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/



ID name of container type of data description of data
1 accessglobal.es communication Peer access records
2 accessvalues.es fed-by fed-by: accessglobal.es to provide options for retrieving linked data hosted elsewhere.
3 ACTIVE_ENTITY.es cache cache of the last loaded entity
4 active_member.es system-lookup a record of the last known system member. Used in auditing and access control.
5 blob_object.es blob a branch-able data container that feeds ingest_commands
6 CLEANEROFCOURSE_MANIFEST.es system-routine instructions on what locations to clean during automation.
7 CONSTRUCTED_core.es system-routine manually or continuously logged communications
8 core.es communications communications general write-to bucket
9 core_packages.es system-routine output of the system-level packages installed by the implementation language
10 data.c structure define input structures. Branch multiple structures into a general binary ready readable and writable container.
11 ENTITY_MANIFEST.es system-routine check and organize what system C.ORE™ is currently aware of
12 HASH_DIRECTORY.es system-routine output information from performing hash verifications on a file
13 KEY.es system-routine provides a lookup match device to use a keycard or other password-less authentication mechanism.
14 log.es system-routine general session specific log output
15 ORE_LEDGER.es entityscript-ore ORE/ retrieval information
16 output_entity.es entity-output take constructed class objects and output them
17 output_flush.es output-flush flush initialized constructed class objects. Free the information buffer
18 output_slug.es output-slug A structured output of a constructed class
19 output_structure.es output-structure comma separated structure table created by the constructed class
20 output_vectorized_data.es output-vectorized-data the same as output_structure but the data is in the form of vector object formatting
21 STRUCTURE.es system-routine the linked attributes currently in place and discoverable by C.ORE™
22 vcnkey.es vcnkey VCNKEY™ based block storage lookup system
23 VISUAL.es system-routine Information to access various visual resources

Alert Types

Alert Types can be used to trigger extended behavior in C.ORE™

FULL LIST COMING SOON

identified signal: THREAT_
SCORE_INFO Create a logged `info` method

identified signal: THREAT_
SCORE_WARNING Create a logged `warning` method

identified signal: THREAT_
SCORE_FAILURE Create a logged `failure` method

Action Tags

Action Tags can be used to track link actions in C.ORE™

Action tags can be used as log augment mechanisms and hold several functions. Here are few.

activation call: ACTION_
REGULAR Standard action recorder

activation call: ACTION_
AUDITED Standard protected action recorder

activation call: ACTION_
ENTITYSCRIPT_RECORDER Used when activating EntityScript™ blocks

activation call: ACTION_
KING_SLUG_RECORDER Used when activating a new active block groups

activation call: ACTION_
SEARCH_RECORDER Used when performing a standardized search lookup


To see more about creating Meta-relationships: Standard Types and core_creator.py, click OpenPackager™