KF-0002 · Controlled Vocabulary and Architectural Distinctions
The authoritative terms of the Knowledge Foundry programme, the distinctions they must preserve, and their user-facing projection
Purpose
This document is the single authoritative home for Knowledge Foundry terminology. It exists so that a term means the same thing in the Canon, the methodology, the architecture, the implementation, the interface and the training material — and so that distinctions the programme depends on are not quietly collapsed by casual synonymy.
It does not re-cut the architecture’s concepts; those are defined in their home documents. It collects them, records the distinctions that must never be treated as synonyms, and defines the small user-facing vocabulary that ordinary users meet in place of the full ontology. Where a definition here and a definition in a home document appear to differ, the home document governs the concept and this document is corrected.
Namespace note. This document is numbered KF-0002 on the assumption that the KF-0000 series is reserved for programme-wide constitutional and navigational artefacts (glossary, programme map, document register). It is deliberately not numbered KF-1001, which is already occupied by the Canon’s opening chapter (“The Nature of Governed Knowledge Systems”). If the KF-0000 series is designated otherwise, this document is renumbered without changing its content.
The document has four sections: authoritative definitions, required distinctions, permitted user-facing language, and mapping rules.
Section 1 · Authoritative Definitions
Terms are grouped by the layer that owns them. Each definition is a compact restatement of the governing document; the citation is the authority.
Constitutional (KF-1000)
- Governed knowledge system — a socio-technical system that holds operational knowledge objects and governs their transition from one justified state to another across modalities (KF-1001).
- Operational Knowledge Object (OKO) — the unit of design: a versioned representation together with its attached evidence, justification and acceptance-state (KF-1101). The system governs the object, never “knowledge itself”.
- Canonical Principle — an enduring obligation true of any governed knowledge system, admitted only if it survives the two-question test (KF-1000 Part III).
- Governance Primitive — one of the six operations by which warrant is conferred: evidence, authority, provenance, validation, versioning, reversibility (KF-1104).
- Constitutional invariant — one of the five properties whose loss would make a system cease to be a governed knowledge system: inspectability, justification, provenance, governed evolution, human accountability (KF-1050).
Lifecycle and method (KF-2000)
- Lifecycle stage — a distinct engineering responsibility with an entry condition and an exit gate (KF-2001).
- Transition — a governed move between states; always attributable and justified (KF-2001).
- Event — an occurrence that triggers a transition; may be raised by a human or an agent, but the transition it triggers remains governed (KF-2001).
- Gate — a justification checkpoint; the point at which an object may advance only if the obligations of its stage are discharged (KF-2001; KF-3005).
- Lifecycle invariant — one of the six continuously checkable properties of an object at every instant: single identity, attributable transitions, justified transitions, inspectable transitions, provenance always present, lineage preserved (KF-2001).
- Materiality — the degree to which an object, claim, decision or transition may affect consequential action, reliance, obligation, exposure, representation or preservation (KF-2003).
- Assurance class — the ordinal grade (A0 Exploratory · A1 Working · A2 Routine · A3 Consequential · A4 Critical) that sets the depth of assurance required; attaches to the release / scope of reliance (KF-2003).
- Governance overlay — an orthogonal attribute (regulated, confidential, public, client-facing, legally-privileged) adding obligations without changing class (KF-2003).
Architecture (KF-3000 series)
- Capability — an enduring ability the architecture must possess, independent of workflow, role, service, technology or modality (KF-3002).
- Service — a logical mechanism with defined responsibility that realises capabilities and maintains records (KF-3003).
- Component — the technical element that implements part of a service (KF-4000).
- Practice — the disciplined human or socio-technical method by which work is performed (KF-2002).
- Control — a reusable mechanism that establishes whether one required condition holds; protects an obligation, risk, policy or invariant (KF-3005).
- Information / Record object — a structured unit of governed information with one authoritative maintaining service (KF-3004).
- Evidence record — the durable record that a material obligation or decision was discharged; wherever possible emitted by the governed act itself (KF-3004 §5.2).
- Conformance claim — an assertion that an object is governed, accepted, current or reliable, reconstructable to the depth its reliance requires (KF-3007).
- Release — a version authorised for a defined scope of operational reliance; the anchor to which assurance class attaches (KF-3000 §2).
Navigation (KF-3009, KF-0001)
- Relationship — a semantic connection between architectural elements; the canonical relationship types are fixed in KF-3009 §10.
- Dependency — a relationship in which one element requires another for correct operation. Every dependency is a relationship; not every relationship is a dependency.
- Traceability — the ability to reconstruct lineage across one or more relationships using observable evidence (KF-3009; KF-3006 §10). Traceability is what makes a relationship demonstrable rather than merely asserted.
Section 2 · Required Distinctions
These pairs carry the programme’s intellectual weight. They must not be treated as synonyms in any document, interface or procedure. Collapsing any one of them re-introduces the ambiguity the discipline exists to resolve.
| Distinction | The difference that must be preserved |
|---|---|
| Evidence vs. justification | Evidence is what supports a claim; justification is the reasoned case — including counter-evidence, assumptions and rationale — for why it may be believed. |
| Justification vs. acceptance | Justification establishes why an object may be believed; acceptance establishes that an identified authority will rely on it. Neither substitutes for the other. |
| Principle vs. invariant | A principle governs progression (what a transition must earn); an invariant governs conformance (what must remain true at every instant). |
| Capability vs. service | A capability is what must be possible; a service is one mechanism by which it is delivered. A capability need not reduce to a single service. |
| Object vs. representation | The object is the enduring governed identity; a representation is one form of its content. One object may have several representations. |
| Identity vs. version | Identity is immutable and singular; a version is one immutable state of the object’s content under that identity. |
| Provenance vs. lineage | Provenance is origin and derivation of content; lineage is the historical relationship between objects and versions (branch, supersede, consolidate). |
| Transition vs. event | An event is what happened; a transition is the governed move it triggers. An event never bypasses a gate. |
| Control vs. gate | A control tests one condition; a gate orchestrates several controls into one decision (KF-3005 §29). |
| Evidence record vs. conformance claim | An evidence record is the durable proof an obligation was discharged; a conformance claim is an assertion reconstructable from such records. |
| Assurance class vs. maturity profile | A class grades how much rigour a particular object is governed to (KF-2003); a maturity profile describes how much architecture an implementation has stood up (KF-3000 §20). |
| Relationship vs. dependency vs. traceability | A relationship is any semantic connection between elements; a dependency is a relationship of required operation; traceability is the reconstruction of lineage across relationships from observable evidence (KF-3009). |
Section 3 · Permitted User-Facing Language
Ordinary users experience governance; they do not study its ontology. Interfaces and operating procedures may use the following five-state vocabulary in place of the internal lifecycle states. These terms are controlled projections of the architecture — simplifications sanctioned here — not replacements for the formal vocabulary, which continues to govern beneath them.
| User-facing term | What the user understands |
|---|---|
| Draft | Being worked on; not yet approved to rely on |
| Under Review | Being checked; approval not yet complete |
| Approved | Approved to rely on, within a stated scope |
| Needs Updating | Something has changed; its currency is in question |
| Superseded | Replaced by a newer object or version |
No other user-facing state names are sanctioned without amendment to this document. Assurance class may be surfaced to users in plain terms (e.g. “for significant decisions”) but the class codes A0–A4 are architectural, not user-facing.
Section 4 · Mapping Rules
The user-facing terms map to internal architecture as follows. The mapping is the contract: an interface showing a user term asserts that the corresponding internal condition holds.
| User-facing term | Internal meaning |
|---|---|
| Draft | Object exists but is not accepted for operational reliance (pre-Acceptance lifecycle states) |
| Under Review | One or more required evaluation or justification activities are incomplete (Evaluate / Justify stages, or a returned object) |
| Approved | Accepted for a defined scope of reliance (Acceptance recorded; a valid Release within scope) |
| Needs Updating | A currency or validity condition has been breached or questioned (a Continuing-Review or dependency event has fired) |
| Superseded | A successor object or version has replaced the object for defined use (Supersession Link recorded; lineage preserved) |
Rules of use. 1. A user term may be shown only when its internal condition is satisfied; the interface does not assert states the architecture has not reached. 2. The mapping is many-to-one downward: several internal states may present as one user term (e.g. Evaluate and Justify both present as Under Review). It is never one-to-many: a single internal condition does not present as two contradictory user terms. 3. The internal state remains the source of truth for every governed decision. User terms are for comprehension, not for authority.
Status and Maintenance
This document is Draft for Experiment. The five-state projection and the required distinctions are to be tested against the first vertical slice: does the five-state vocabulary suffice for a real user of a Consequential object, and do the distinctions hold up when one object is taken end to end? It moves to Approved after that evidence. The glossary is maintained as a controlled vocabulary in its own right — changes are governed, attributable and versioned, exactly as the architecture requires of any governed record.