Teminnology : Biligent#2

Overview of Biligent

2. Terminology

Term	Definition	Behavioral Definition Location
Domain	A workbench unit (one domain DB) that isolates source data and its learning results from other domains.	§4-5 domain_lifecycle · §7 store
Connectivity graph	A representation of data structure through connections between nodes (multi-layer structures and cross-table connections).	§4-5 connectivity · §7 connectivity
Node	An element of the connectivity graph. There are four node types: column name, key name, status value (under a key), and condition value. A measurement value is not a node; it is represented as a value range of a column/key node. A table is an element of the node-identification path, not a node itself. An identifier is initially defined by its path and linked through the alias ledger when the path changes.	§6 UR-09 · §6 UR-16 · §7 contracts
Node Classification Change Value	A value selected by the classification dropdown — the five values consisting of the four node types plus measurement value, which represents value distinctions for column/key nodes.	§6 UR-16 · §7 user_input
Value Role	A classification of the nature of a value: measurement value, status value (the state or mode of the measured subject itself), and condition value (an external condition of the measured subject).	§6 UR-06 · §6 UR-20 · §7 value_roles
Format Signature	A hash generated for each node from its table/column structure, value format (delimiters/packed keys), value-role distribution, and node identifier, plus an overall connectivity-graph signature generated from the node signatures. It is the identity criterion for reusing user-certified items. Each element is calculated from the original source before user corrections or learning are reflected.	§6 UR-19 · §7 connectivity
Format Rule	A definition of delimiters, delimiter roles, and packed-data decoding (FormatSpec) for value formats. It is applied to format units with the same format key, and certified rules become inputs to data interpretation. It is the format type of a correction rule; the “structure rule” in §6 UR-10 is the same concept as a format rule.	§6 UR-10 · §6 UR-19 · §7 meaning_structure
Format Key	A deterministically calculated key from FormatSpec used to determine whether formats are identical. The delimiter characters themselves are not included.	§7 contracts
Correction Rule	A declarative rule (CorrectionRule) containing a correction method provided by the user. Each type (format, connectivity, role, node classification — an open-ended list) has target-selection conditions and a method. Once certified, it becomes an interpretation input (rules) for analysis, reanalysis, and additional uploads, and is applied to all matching targets. It is registered in the knowledge registry and follows grading, rejection, and rollback procedures. User-defined rules are reapplied after reset or migration to format units having the same value format.	§7 contracts · §7 meaning_structure · §6 UR-19
Semantic Rule	A rule that attaches meaning to a format key, together with companion-key/value conditions when applicable. It applies to all values and columns of the same format and has common and user-specific scopes.	§4-5 meaning_structure · §7 meaning_structure
Knowledge Grade	The grade of a knowledge item: Needs Review (agent candidate), Approved, and Certified. Only a person can perform the transition to Certified. Review flags, provenance, scope of application, and closure status (active/rejected/replaced) are separate axes from the grade. Approved and Certified may also be referred to as approved and certified.	§4-5 knowledge_policy · §7 knowledge_policy · §7 contracts
Needs Review	A marker attached until human confirmation to values initially determined by an agent (knowledge candidates, value roles, data-type assignments, and draft evaluation-question sets). It is distinct from “unconfirmed” in calculation plans and user-input meanings, which indicates that a calculation definition has not been finalized or agreed upon.	§6 UR-20 · §6 UR-17
Version & Provenance	An append-only version number and Provenance (who, when, why, from which input, and by what method) recorded by writes that store learning and user input. A rollback creates a new version from a previous version; version numbers increase monotonically across resets.	§7 contracts · §7 meaning_structure
Dependency Reference	A versioned reference (DependencyRef) carried by answer records, derived lineage, and events. It is the basis for invalidation and reproducibility.	§7 contracts · §7 conversation
Open List	A registry in which adding values is an incremental extension. A receiving component treats unknown values as “unknown.”	§7 contracts
Concept Ledger	A record containing terms, aliases, scopes, and links among nodes, edges, rules, calculation definitions, and other concepts. The search index is created from the registry's search terms.	§7 meaning_structure · §7 retrieval
Input Document Type Table	The authoritative definition of user-document types outside data files and their attributes (series, receiving path, receiving function, whether kind is included, incoming round, whether a registration event is emitted, and reader).	Format §7 contracts · Value §7 user_input, item 3
Storage Scope	The domain DB, integration DB, and global assets — including module-level table placement and migration units.	§7 store
Node Filter	A list of node references assigned to data types permitted for a user, together with whether the filter is applied (NodeFilter). access provides the list, while calculation and evidence modules only hide nodes outside the permitted list.	§4-6 Dependency Rule 3 · §7 access
Draft	A stored node opinion and planned node-status/classification change before application. It can be edited or deleted before application, persists across session termination, and is applied in bulk.	§6 UR-15 · §7 user_input
Structural Modification	User input for changing nodes, connections, node types, roles, and format rules in the connectivity graph, including withdrawal of a certified modification. It is applied after data verification → reporting → user confirmation.	§6 UR-10
Calculation Plan (`CalcPlan`)	A list of stages for answer calculation, including parameter lists (corresponding slot items and defaults), target declarations, per-stage type/parameters/method/input/output form/reason, references to certified calculation definitions, and an unconfirmed marker. Stored calculation rules (CalcRule) use the same staged form, and answers, precomputation, and reproduction are executed by the same runner.	§6 UR-17 · §7 contracts · §7 calc_runner
Exclusion Record (`Batch`)	A stage-level record format containing rows used in calculation (included) and rows excluded (excluded), including references, reason codes, stages, and details.	§6 UR-24 · §7 contracts
Development Cycle	One pass through eight stages from planning to verification in the real environment. One round constitutes one development cycle.	§9-5
Round	One row (R0–R12) in the round-order table, representing the modules/connections introduced in that cycle and its completion criteria.	§9-2 Round Order Table
Major Group · Middle Group · Package	Package = small group (modules in the package-layer table); middle group = intermediate integrations and foundations; major group = management-level grouping A–E (not a code layer).	§4-7 Major/Middle/Small Group Structure
Agent	A unit satisfying four conditions: its own trigger, decision among options, delivery of contract results, and failure disposition. Deterministic calculations, validation rules, and records are components, not agents.	§4-1 · §4-3 Agent Layer Table · §8
Foundation Module	A module jointly used by multiple intermediate integrations. It does not import functional modules.	§4-6 Dependency Rule 1 · §4-7 Major/Middle/Small Group Structure
Intermediate Integration	A unit that groups related functional modules together.	§4-4 Package Layer Table · §4-2 Architecture Diagram
Orchestrator	The top-level module responsible for bootstrap, domain-specific workbench configuration, lifecycle, schedule execution, hook and initialization handling, registration of migration functions, and initial server-administrator registration.	§4-2 Architecture Diagram · §4-6 Dependency Rule 6 · §8
Reset	Clearing a domain's learned content within a defined scope. Retention and preservation scope follow the relevant behavioral definition.	§4-5 domain_lifecycle · §7 domain_lifecycle
Review	Turning on a knowledge review marker, which is a separate axis from the grade. The grade and usage remain unchanged while the item is marked “under review”; this is distinct from reset.	§6 UR-14 · §7 knowledge_policy
Migration	Copying and applying user-certified items from an existing domain with the same overall connectivity signature to a new domain, including data-type assignments confirmed by the domain administrator and excluding clarification records.	§6 UR-19 · §7 domain_lifecycle
Server Administrator	A permission layer for server-wide operations (account registration, domain creation, designation of the first domain administrator, adoption of global assets, and server-to-server import). The initial server-administrator account is an installation setting. One person may also hold a domain-level grade.	§5-5 · §7 access
Domain Permission Grade	The set of grades assigned to a person for each domain: Domain Administrator (including all view and learning operations), View + Learning, and View Only.	§5-5 · §7 access
Permission Table	Declarative data containing permission status and whether learning signals may be used for each grade × operation type. It is the sole authority for permission decisions.	§5-5 · §7 access · §7 contracts
Learning Signal	A marker indicating whether user actions may be used in knowledge, score, demand, interest, and metric records. Recording points do not compare grades; they follow the learning-signal field of the permission table (the result of authorize).	§5-5 · §8 A0
Account	A permitted access unit registered with an authentication method (open list — Google OAuth or ID/password) and an external authentication identifier. Unregistered accounts cannot access the system.	§7 access
Slot	A placeholder for which only the interface is defined and no implementation round is assigned (integration-management agent, web_search).	§11
Requirement Item	A requirement (RQ-nnn) received by this deliverable, with an assigned accepting module and round.	§3
User Decision Rule	A rule (UR-nn) defining behavior between modules, with an application location and round.	§6
Item Closed by the Implementation Plan	A wiring or detailed item (CL-nn) that is defined and closed by a round implementation plan.	§9-7