ChiralityRoot · normative emphasis · Manuscript fc92dd39c2 ↗ · Exact Markdown
Glossary
These definitions explain the thesis. They create no new repository procedures or product permissions. Current instructions and adopted product contracts govern their consumers. Historical terms are retained in the second table so older architecture descriptions remain readable without reinstating their mechanisms.
Current conceptual and operational terms
| Term | Definition | Source |
|---|---|---|
| Acceptance | An authorized act concerning an identified subject, scope and purpose. It differs from a successful operation or passing check. Professional authentication is a particular act under applicable professional obligations. | Shared conclusion; Chapter 6 |
| Accountability gap | The non-identity between externalizable information and accountable knowing. It is not the operational Gap that further evidence can address. |
Chapter 3 §3.6.2 |
| Agent 0 | Responsibility for purpose, alignment, continuity and reserved choices with the owner, held by the agent working with that person regardless of its entry role. Other roles are engaged as useful. | AGENTS.md; Chapter 3 §3.2.3 |
| Agent 1 | A manager contribution: HELPS_HUMANS develops intent and design; WORKING_ITEMS owns implementation and integration. The type does not require a separate session or universal delegation stage. | AGENTS.md; agents/AGENT_HELPS_HUMANS.md; agents/AGENT_WORKING_ITEMS.md |
| Agent 2 | TASK, a bounded executor that carries an assignment through ordinary repairs and does not delegate. Its caller owns integration. | agents/AGENT_TASK.md |
| Artifact | A work product or representation available for use or examination. Its form follows the undertaking; no universal four-document kit is required. | Chapter 3 §3.2.1 |
| Assumption | A provisional basis for reasoning. It remains distinct from observation even when use of it is authorized. Its grounds, limits and effect on the work must be considered. | Chapter 3 §3.2.2 |
| Authentication | An attributable professional act accepting responsibility for reliance on identified content within a scope and purpose. It does not create knowledge, establish truth or make a record proof of adequate engagement. Applicable professional requirements determine when and how authentication is required. | Chapter 3 §§3.6.1, 3.6.7; Chapter 6 |
| Authorization | Permission in the normative sense to undertake an action under an applicable assignment and governing commitments. An available tool or technical permission does not alone confer it. | Shared conclusion; Chapter 4 |
| Axiology | Inquiry into purposes, values and consequences. Public welfare and professional responsibility are central in this setting; attention, maintainability, agency and delay are also relevant to evaluating controls. | Chapter 3 §3.2.4 |
| Brief | The assignment establishing an objective, context, authority, limits and expected result. It may be supplied in the conversation; a separate record is not inherently required. | agents/AGENT_TASK.md |
| Capability | What an agent, person or tool can do under the stated conditions. Capability does not establish authorization, appropriate use or sufficient evidence for reliance. | Shared introduction; Chapter 3 |
| Chirality (of knowledge) | The framework's bounded metaphor for the accountability gap. It supplies no geometry of knowledge and does not make every architectural distinction independently chiral. | Chapter 3 §3.6 |
| Claim | An assertion about a subject. A clear statement or plausible output is not self-certifying. | Chapter 3 §3.2.2 |
| Commitment | An adopted obligation or a person's engagement with what they will stand behind. The subject and authority must be clear; a candidate mechanism is not automatically a commitment. | Chapter 3 §§3.2.2, 3.6.4 |
| Configurational multiplicity | The openness by which identical information can occasion different knowledge across people, purposes, contexts or times. It does not make interpretations equally well supported. | Chapter 3 §3.6.3 |
| Conflict | Incompatible claims requiring examination of their sources, scope or meaning. Inquiry can resolve some conflicts; a reserved choice must reach its decision owner. | Chapter 3 §3.2.2 |
| Content-addressed approval | An approval tied to identified content, such as a Git SHA. For consumers that adopt K-AUTH-2, changing that content voids its approval. A hash establishes identity, not correctness or engagement; it creates no general reapproval gate for authorized development. | docs/PRODUCT_BOUNDARIES.md; Chapter 3 §3.2.2 |
| Decision capture | Preserving an attributable decision where it governs work and retaining the reason in the existing change record. It does not require an append register. | AGENTS.md |
| Decision right | Authority to make a particular choice. Current repository commitments, acceptance criteria, releases, risk acceptance and explicit holds retain owner-reserved choices; ordinary work proceeds within existing authorization. | AGENTS.md |
| Deliverable | An intended work product within an undertaking. In active repository projects its folder holds ScopeOfWork, useful Design and declared needs. The folder is a representation and working home, not proof of completion or acceptance. | AGENTS.md; Chapter 3 §3.2.1 |
| Dependency | A consumer's need for a contribution or condition. Current deliverable.yaml files state needs; tools derive reverse links and graph views. A missing edge does not establish independence. |
AGENTS.md; tools/deliverables/README.md |
| Design hypothesis | A proposed mechanism for supporting a commitment. Its coherence does not establish its performance, adequacy or comparative value. | Chapter 3 §3.1 |
| Direct supervision and control | A professional oversight obligation discussed in Chapter 6. Its satisfaction depends on applicable standards and actual practice, not the presence of a particular agent hierarchy or approval form. | Chapter 6; APEGA, Relying on the Work of Others and Outsourcing |
| Downstream | A consumer of a contribution or result. In the current dependency model the consumer states the need and tools derive the reverse relationship. | tools/deliverables/README.md |
| Empirical finding | An observation or result under identified conditions. It supports claims within those conditions and its evidential limits. | Chapter 3 §3.1; Chapter 8 |
| Engineering adequacy | Whether a proposed arrangement serves its intended use under the relevant requirements, conditions and consequences. Numerical verification and operation validation provide narrower evidence. | Piping thesis; worked example |
| Epistemic label | A classification such as FACT, ASSUMPTION, PROPOSAL or TBD where useful or required by a consumer. Its presence cannot establish the adequacy of its grounds or exhaust the person's knowing. | Chapter 3 §3.2.2 |
| Epistemology | Inquiry into knowing, grounds, uncertainty and the limits of claims. Evidence, examination and accountable reliance remain different relationships. | Chapter 3 §3.2.2 |
| Fact | In the historical labeling convention, a claim based on direct observation or an accurately cited source. Observation has a source and scope; the label itself is no guarantee of truth. | Chapter 3 §3.2.2 |
| Gap | Missing grounds or information whose effect on the work matters. Evidence can address it; a decision can authorize action under uncertainty without manufacturing the missing grounds. | Chapter 3 §§3.2.2, 3.6.2 |
| Gate | A decision boundary imposed by applicable authority or a requirement. An agent may not bypass it, but responsible work does not imply a gate at every phase. | AGENTS.md; Chapter 3 §3.2.3 |
| Information | An externalizable substrate that can be recorded, transmitted, copied, cited, compared and organized. It may occasion knowing without being identical with the knower's achievement. | Chapter 3 §3.6.1 |
| Integration | Bringing related contributions into a usable result, including their interfaces and unresolved matters. It requires an owner but not necessarily a separate agent. | workflows/coordinated-knowledge-work/WORKFLOW.md |
| Invariant | A constraint intended to hold within a specified system or operation. Its scope and actual enforcement must be stated. A written invariant is not itself a mechanical guarantee; retained product identifiers apply only to adopted consumers. | docs/PRODUCT_BOUNDARIES.md; Chapter 7 |
| Iteration | Reconsideration and action informed by what the work reveals. It may repair a result, revise a method or prompt an authorized change to a purpose or criterion. Repetition alone does not establish learning. | Shared introduction and conclusion |
| Judgment | The person's situated, committed, world-involving engagement with what the work means, what matters and what they will stand behind. It shapes purpose, framing and action throughout the undertaking. Final approval is one expression, not its definition. | Smith, The Promise of Artificial Intelligence (2019); Chapter 3 §3.6.4 |
| Knowledge graph | A representation of selected entities and relationships useful to inquiry. It is a view with a basis and limits, not an exhaustive model of knowing or an independent authority source. | Chapter 3 §§3.2.1, 3.6.3 |
| Knowledge | A situated achievement of a knower. In this framework's deliberately non-factive usage, knowledge may be mistaken, incomplete, provisional or revised. Authentication does not confer it on information. | Chapter 3 §3.6.1 |
| Licensed professional | A person holding an applicable professional licence and subject to its obligations. Agent output does not transfer the responsibility the professional accepts for reliance. | Chapter 6 |
| Meaning | Use depends on the subject: existential significance in the philosophical account, domain interpretation of represented objects, or specified semantics of an operation. These are related uses, not interchangeable definitions. Appendix D gives M its narrower approved definition. | Shared introduction; Chapter 3; Appendix D |
| Model applicability | Whether an idealization and its inputs suit the situation and question being examined. Verification that code calculates that idealization correctly does not establish applicability. | Piping thesis; worked example |
| Normative commitment | A value, responsibility boundary or obligation the undertaking adopts or must meet. It is distinct from the claim that a chosen mechanism successfully serves it. | Chapter 3 §3.1 |
| Objective | The intended result or purpose of the current undertaking, established through the relevant authority. Archived plans do not create a standing backlog. | AGENTS.md |
| Ontology | Inquiry into what kinds of things and relationships matter. Domain entities, their representations and implementation conveniences must remain distinguishable. | Chapter 3 §3.2.1 |
| Operation semantics | The specified meaning of an action: its subject, preconditions, effects and outcomes. Fidelity includes preserving the distinctions needed to interpret and use the result. | App thesis; Piping thesis |
| Package | An organizing partition of scope. Current repository deliverables use package folders; this organization does not exhaust domain relationships. | AGENTS.md |
| Permission (host) | A technical allowance or restriction enforced by the host on a controlled execution path. It can constrain authorized work; its presence does not make all technically possible work authorized. | Shared conclusion; Chapter 4 |
| Permit Holder | An organization or entity holding an applicable professional permit, with responsibilities determined by that regulatory context. | Chapter 6 |
| Praxeology (also praxiology) | Inquiry into how intention becomes usable work through investigation, production, examination, repair and integration. It does not prescribe fixed staffing or a universal gate sequence. | Chapter 3 §3.2.3 |
| PROPOSAL | A candidate interpretation or action. Its adoption depends on the assignment and applicable decision rights; not every ordinary implementation proposal requires renewed owner approval. | Chapter 3 §3.2.2 |
| Provenance | Identification of relevant sources, transformations and attribution. The detail required depends on the claim and its consumer; source presence alone does not establish fidelity or support. | Chapter 3 §3.2.2 |
| PWP (Professional Work Product) | A professional-practice category discussed in Chapter 6 for outputs on which others rely. The licensed professional determines the applicable standing and authentication requirements; neither agent completion nor a passing check confers professional approval. | Chapter 6; APEGA, Authenticating Professional Work Products |
| Reckoning | Computational activity that can include sophisticated investigation, inference, assessment, planning, comparison, checking and adaptive action within authority. Greater capability does not itself supply the person's committed judgment or transfer professional responsibility. | Smith, The Promise of Artificial Intelligence (2019); Chapter 3 §3.6.4 |
| Responsible member | A role under the applicable professional permit and practice requirements. Its obligations must be read in that context, rather than inferred from an agent-role label. | Chapter 6 |
| Role | A description of a contribution and responsibilities. The assignment establishes authorized work; the host supplies capabilities and enforces permissions. A role name confers neither. Role choice does not require a separate session. | AGENTS.md; agents/AGENT_HELP_HUMAN.md |
| Ruling | An attributable decision within the issuer's authority. It can settle a choice or authorize action under uncertainty without making an uncertain premise true. | Chapter 3 §3.2.2 |
| Scope item | A stated part of the intended work or commitment. Its identity and traceability should support actual production and examination. | Chapter 4 |
| Stable identifier | An identity preserved where needed across changes of name, path or representation. Stability aids traceability without establishing content equivalence. | Chapter 4 |
| Stage gate | A specifically adopted milestone or reserved decision, whose subject and acceptance authority are defined. It is not implied by routine development or a lifecycle label. | AGENTS.md; Chapter 6 |
| Task agent | TASK, a bounded executor that stays with its assignment through ordinary repairs, reports blockers accurately and does not delegate. Its assignment may be the conversation. | agents/AGENT_TASK.md |
| TBD | A marker for missing information or grounds. It must not be replaced by an invented value merely to complete a representation. | Chapter 3 §3.2.2 |
| Thorough review | Professional examination sufficient for the reliance under consideration, subject to applicable standards. A record of review does not by itself establish that the examination was adequate. | Chapter 6 |
| Upstream | A supplier or input required by a consumer under a stated condition. Presence does not establish suitability. | tools/deliverables/README.md |
| Validation | A qualified examination: operation validation checks declared conditions for an action; validation in use examines fitness for an intended activity. State the subject, conditions and claim. Neither use of the term implies professional acceptance. | Chapter 7; App and Piping theses |
| Verification | Examination against a specified claim or reference. Implementation verification concerns prescribed behaviour; numerical verification concerns calculations for identified models, cases and tolerances. Neither alone establishes fitness for the intended engineering use. | Chapter 7; Piping thesis |
| Warrant | Grounds relevant to a claim, such as sources, observations, calculations, tests or arguments. Model confidence alone is not a warrant; evidence must be assessed for scope and adequacy. | Chapter 3 §3.2.2 |
| Work graph | A view used to coordinate contributions and dependencies. Current repository practice derives relationships from the work and tools rather than requiring a hand-maintained progress register. | AGENTS.md; workflows/coordinated-knowledge-work/WORKFLOW.md |
| Write scope | The targets permitted by the assignment, applicable requirements and host permissions. A declaration and a mechanically enforced boundary are different claims. | AGENTS.md; tools/workflow_runtime/resolve_workflow.py |
Historical mechanism terms
These terms explain earlier designs. References to TYPES.md, DIRECTIVE.md
and similar removed documents refer to their archived versions, recoverable
from archive/pre-docs-cleanup-1. They impose no new current development duty.
A retained product contract may still adopt a specific legacy format; consult
docs/COMPATIBILITY_FORMATS.md for those consumers.
| Term | Historical meaning | Current interpretation |
|---|---|---|
| Anchor (dependency class) | A dependency row linking a deliverable to a definition or traceability node | One historical way to represent vertical context; useful references now remain with their current source |
| Brief-driven pipeline | A structured INIT-TASK brief followed by straight-through execution | An assignment can supply the necessary boundaries without a new form or a prohibition on ordinary repair |
| Coordination representation | SCHEDULE_FIRST, DEPENDENCY_TRACKED or HYBRID in _COORDINATION.md |
Historical orchestration choices, not a required project classification |
| Coverage and telemetry | A decomposition summary of counts, gaps and open issues | Evidence should answer an actual completeness or performance question |
| Datasheet | The parameters and identity member of the four-document kit | A useful document form where needed, not the mandatory embodiment of ontology |
| Document kit | Datasheet, Specification, Guidance and Procedure for every deliverable | Replaced as a universal repository requirement; the four questions need not have four files |
| Execution (dependency class) | Dependency rows for prerequisites, information flow and constraints | Current needs preserve their conditions without requiring the legacy row model |
| Filesystem-as-state | The claim that all governed project state exists in versioned files | Current sources remain inspectable, but conversation can establish intent and authority, and product engines can own domain state |
| Guidance | The rationale and context member of the document kit | Useful reasoning belongs in the artifact where it governs the work |
| Hybrid posture | An interactive persona over a bounded pipeline | A historical execution pattern, not an exhaustive classification of sessions |
| INITIALIZED | A lifecycle state indicating that a document kit was drafted | Retired lifecycle label in active repository development |
| IN_PROGRESS | A lifecycle state indicating ongoing work | Retired lifecycle label; queries and actual work provide relevant facts |
| Instruction root | A release-managed App bundle of instruction resources | A product arrangement where adopted; it does not establish a universal runtime or repository authority hierarchy |
| ISSUED | A lifecycle label for released work | Release remains an attributable act under applicable authority; active development uses no universal issuance status file |
| Knowledge decomposition marker | Text enabling knowledge-type scope selection in older tools | A historical routing convention, not a condition of knowing |
| Knowledge type option | A file-type selector including Context, Status, Semantic and Memory | Legacy selector categories, not an exhaustive ontology |
| OPEN | A lifecycle state for a minimum folder set | Retired lifecycle label in active repository development |
| Persona agent | A conversational role contrasted with straight-through tasks | Current roles describe contributions; the host and assignment govern execution |
| Pointer file | A mutable reference such as _LATEST.md to an immutable snapshot |
A useful mechanism only where a consumer needs it |
| Scope ledger | A table mapping scope items to packages and deliverables | Historical completeness mechanism; current work does not require another register |
| SEMANTIC_READY | A lifecycle state indicating a semantic lens existed | Retired lifecycle label; a lens can still assist inquiry without establishing readiness |
| Snapshot | An immutable per-run output bundle under a tool root | Preserve exact versions when needed for review, reliance or recovery; no universal per-run packet is required |
| Supervised many-to-many agency | Parent-mediated coordination between active children | One historical coordination pattern; it does not mandate relay chains |
| Terminal fan-out/fan-in | Dispatch children, await terminal returns, then release dependent work | Actual returns still require inspection; independent work need not wait for unrelated contributions |
| Tool root | An isolated directory for derived outputs and reports | Isolation can support a bounded operation; agents may also edit authorized current deliverable sources |
| Vocabulary map | A decomposition table of canonical terms and synonyms | A tool for resolving actual ambiguity, not a compulsory artifact |
| Warrant lifecycle | UNWARRANTED → CITED → REVIEWED → AUTHENTICATED |
A historical mnemonic that combines evidential, review and normative relationships; not a universal progression |
| Working root | A user-selected project folder separated from bundled instructions | A product location distinction where adopted, not proof that all state lives there |
| WRITE_SCOPE | An enumerated property formerly required in agent headers | Authorization derives from the applicable assignment and governing commitments; host permissions separately constrain execution |
| Write quarantine | Separation of tool outputs from accepted source material | A candidate containment mechanism, not a universal prohibition on agent edits to current work |
Implementation evidence basis: a602024416. Manuscript publication revision is identified above.