KF-3002 · Capability Model

The Required Abilities of a Governed Knowledge Architecture

Reference Architecture · Draft · v0.2 · 47 min read

Canon and Method
KF-1000 / KF-2001 / KF-2002
        ↓
Reference Architecture
KF-3000
        ↓
Architectural Rules
KF-3001
        ↓
▸ Capability Model
KF-3002
        ↓
Logical Services, Records and Controls
KF-3003–KF-3009
        ↓
Implementation
KF-4000

Purpose

KF-3002 defines the architectural capabilities required to realise the Knowledge Foundry methodology and preserve the principles, invariants and interaction constraints established in KF-3001.

A capability is an enduring ability the architecture must possess, independent of organisational workflow, accountable role, logical service arrangement, information-storage model, technology, vendor, deployment topology or computational modality.

KF-3002 answers: What must a conforming Knowledge Foundry architecture be able to do? KF-3003 answers: Through which logical services are those abilities exposed and coordinated? KF-3004 answers: Through which records and relationships are those abilities represented and evidenced? KF-3005 answers: Through which lifecycle controls are those abilities constrained?

Capability Derivation

Every capability must be traceable to an upstream obligation.

Canonical Principle
        ↓
Lifecycle or Practice Obligation
        ↓
Architectural Principle, Invariant or Constraint
        ↓
Required Architectural Ability
        ↓
Capability
        ↓
Logical Service
        ↓
Implementation

A capability belongs in KF-3002 only when its absence would leave a Canonical PrincipleCanonical Principle — an enduring obligation true of any governed knowledge system, admitted only if it survives the two-question test (KF-1000 Part III). Vocabulary →, a lifecycle stage/gate/invariant, an engineering-practice obligation, a mandatory engineering artefact, a KF-3001 invariant or interaction constraint, or a conformance requirement unsupported.

Capability Admission Test

A proposed capability is admitted only where it expresses an enduring architectural ability; is independent of any specific technology or organisational procedure; has an identifiable upstream basis; has observable required behaviours; has identifiable information objects and relationships; would create a defined architectural risk on failure; has demonstrable conformance; and is not already fully contained within another capability.

Capability Boundaries

A capability is not a lifecycle stage, an engineering practice, a logical service, a human role, an artefact, a control, an application feature or a technology component. The relationships are:

Practice   establishes an engineering obligation
Capability states the ability required to discharge it
Service    exposes and coordinates that ability
Record     preserves its governed information and evidence
Control    limits or verifies its exercise
Role       holds authority or accountability where required

Part I · Capability Model Foundations

1. Capability Domains

The model contains five capability domains and twenty-four constituent capabilities.

Domains A–D describe the abilities that act upon the Operational Knowledge ObjectOperational Knowledge Object — 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". Vocabulary → and its operational life. Domain E is cross-cutting: it does not author, evaluate or alter the substantive content of an Operational Knowledge Object, nor does it independently authorise lifecycle transitions. It preserves and evaluates the provenance, integrity, temporal condition, protection and conformance evidence surrounding that content.

2. Capability Levels

KF-3002 uses two levels. A domain capability is a broad architectural ability grouping related subordinate capabilities (for example, Operational Governance). A constituent capability is a bounded, independently testable architectural ability (for example, Authority and Acceptance Management). KF-3002 does not decompose below constituent capability level; detailed service operations belong in KF-3003 and implementation functions in KF-4000.

3. Capability Specification

Each constituent capability is specified through eleven fields:

• Capability statement — the enduring ability;
• Purpose — why the ability is required;
• Upstream derivation — practices, principles, invariants and constraints;
• Scope — what falls inside and outside the capability;
• Required behaviours — what the architecture must be able to do;
• Principal information objects — the logical information structures acted upon or produced;
• Capability relationships — typed relationships to other capabilities;
• Protected invariants — KF-3001 invariants preserved;
• Operating criticality — the consequence of the capability’s inability or degradation;
• Failure conditions — what inability or misuse looks like;
• Conformance condition — observable proof that the capability exists.

A principal information object is a logical information structure created, consumed or maintained by a capability. It may be an engineering artefact, governed record, representation, decision, status, linkage or result. It is not necessarily an Operational Knowledge Object; the OKOOKO — 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". Vocabulary → is the governed subject, while information objects are the structures through which capabilities act upon and evidence it.

Operating criticality classifies the consequence of a capability being unavailable or degraded, using the categories: conformance-critical, governance-critical, operationally critical, recoverable with bounded manual control, and advisory. A capability may combine a category with a default failure posture (fail-open or fail-closed). This classification does not set implementation availability targets; it lets KF-3005 and KF-3007 determine the consequence of unavailability.

4. Capability Relationship Types

Capabilities relate through five typed relationships, replacing any single undifferentiated notion of dependency:

• Prerequisite — an ability that must already exist or produce an input before this one can operate;
• Collaborating capability — an ability participating with this one in the same governed operation;
• Constraining capability — an ability that limits or validates this one’s execution;
• Triggered capability — an ability invoked as a consequence of this one;
• Evidence provider / consumer — an ability supplying, or receiving, conformance evidence.

Typing these relationships removes false circularity: two capabilities that collaborate in one operation are not mutual prerequisites. Relationships do not create authority; authority is assigned through KF-3008.

5. Common Capability Requirements

Every capability must:

1. preserve the relevant KF-3001 invariants;
2. operate within the applicable interaction constraints;
3. produce or maintain inspectable evidence of material actions;
4. expose failure, pending and indeterminate conditions explicitly;
5. preserve attribution between human and computational action;
6. operate across supported computational modalities;
7. preserve recorded time and effective time where relevant;
8. preserve the authoritative-maintainer boundary assigned to each information object in KF-3003 and KF-3004, altering such information only through a governed interaction;
9. remain logically distinguishable even where combined physically;
10. support conformance inspection.

Part II · Domain A — Identity & Representation

Domain Statement

The architecture must be able to establish what an Operational Knowledge Object is, preserve its identity and make its representation and context inspectable.

A-CAP-01 · Object Registration

Capability statement. The architecture can register a candidate Operational Knowledge Object and assign it one durable, immutable identity, and can determine how an intake relates to existing objects.

Purpose. Establish the object as a governable entity from the moment of capture, and route the intake correctly without itself performing version or lineage operations.

Upstream derivation. KF-2002 A1; KF-3001 AP-04, AP-10; INV-01; IC-05.

Scope. Includes candidate registration; identity assignment; initial origin capture; duplicate and prior-object assessment; classification of intake as a new object, version candidate, branch candidate or consolidation candidate. Excludes detailed semantic structuring; acceptance; release; the creation of the resulting version, branch or consolidated successor. A-CAP-01 determines whether an intake should create a new object identity or be routed to an existing object’s version or lineage path; it does not itself create the resulting version, branch or consolidated successor (those are C-CAP-04 and C-CAP-06). This preserves the distinction: identity resolution ≠ version creation ≠ lineage operation.

Required behaviours.

• assign an immutable object identifier;
• prevent identifier reuse;
• distinguish object identity from record identity;
• determine whether intake represents a new object or relates to an existing one;
• bind origin and intake context to the identity;
• route version, branch and consolidation candidates to the responsible capability;
• expose ambiguous or unresolved identity conditions;
• prevent progression where identity is absent or conflicting.

Principal information objects. Object Identity Record; Intake Record; Provenance Seed; Identity Resolution Decision.

Capability relationships. - Constrained by: E-CAP-03, E-CAP-04 - Evidence providers: E-CAP-01 - May trigger: C-CAP-04, C-CAP-06

Protected invariants. INV-01; INV-04; INV-11; INV-24.

Operating criticality. Governance-critical; normally fail-closed — no progression without a resolved, unique identity.

Failure conditions. Duplicate identity; reused identifier; unidentified object; origin absent; unresolved ambiguity represented as resolved; version or branch incorrectly registered as an unrelated object.

Conformance condition. For any registered object, an independent reviewer can recover its identity, origin, intake decision and, where applicable, its relationship to predecessor or source objects.

A-CAP-02 · Structured Representation

Capability statement. The architecture can create and maintain an inspectable representation of an object’s semantic content, type, constituent elements and relationships.

Purpose. Enable evaluation, justification, governance, discovery and explanation to operate on explicit representations.

Upstream derivation. KF-2002 A2; KF-3001 AP-04, AP-05, AP-13; INV-02; INV-03.

Scope. Includes semantic typing; constituent claim or element representation; metadata; object relationships; source-to-representation linkage; multiple representations of one object version. Excludes evidence evaluation; justification; operational acceptance; physical representation technology.

Required behaviours.

• assign and maintain semantic type;
• represent constituent claims or elements;
• represent relationships among elements and objects;
• preserve the distinction between content and warrant;
• support human, symbolic, parametric and hybrid representations;
• indicate representation limitations and opacity;
• link every representation to the object and version represented.

Principal information objects. Structured Representation; Semantic Type Record; Metadata Record; Object Relationship Record; Representation Limitation Record.

Capability relationships. - Prerequisites: A-CAP-01 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-01 - May trigger: C-CAP-04

Protected invariants. INV-02; INV-03; INV-04; INV-20.

Operating criticality. Governance-critical — inspectability is a precondition of evaluation, justification and governance.

Failure conditions. Representation not linked to object or version; structure implicit and unrecoverable; type absent or contradictory; semantic relationship lost; modality limitations concealed; content and justification collapsed.

Conformance condition. A reviewer can identify what the representation expresses, which object and version it represents, how its material elements relate and what limitations apply to its modality.

A-CAP-03 · Object Resolution and Contextual Discovery

Capability statement. The architecture can locate and retrieve an object together with the governed context required to interpret its identity, state, warrant, relationships and history.

Purpose. Ensure that retrieval does not detach content from its governance and epistemic context.

Upstream derivation. KF-2002 A1, A2; KF-3001 AP-05, AP-09; INV-02, INV-03, INV-04; IC-12.

Scope. Includes discovery by object identity, version, semantic type, relationship, lifecycle state, epistemic status, steward, lineage, and acceptance or release condition. Excludes ranking algorithms; user-interface design; physical indexes; implementation-specific search technology.

Required behaviours.

• resolve an identifier to exactly one object;
• retrieve current and historical versions;
• expose lifecycle and epistemic status separately;
• traverse object relationships and lineage;
• retrieve relevant warrant and governance context;
• distinguish current, superseded, branched, consolidated, suspended and retired objects;
• prevent context-free retrieval from being represented as governed knowledge.

Principal information objects. Resolution Result; Governed Context Package; Relationship Path; Lineage Path; Retrieval Provenance Record.

Capability relationships. - Prerequisites: A-CAP-01, A-CAP-02 - Constrained by: E-CAP-03 - Evidence providers: B-CAP-04, C-CAP-08, E-CAP-01

Protected invariants. INV-01; INV-02; INV-03; INV-04; INV-17.

Operating criticality. Recoverable with bounded manual control — discovery may degrade for a bounded period without blocking governed transitions, provided degradation is visible.

Failure conditions. Ambiguous resolution; stale version presented as current; content retrieved without its relevant acceptance or warrant; retired or suspended status concealed; lineage or relationship path broken.

Conformance condition. Given a valid retrieval request, the architecture can return the correct object and enough governed context to determine what it is, which version is being inspected, its present standing and the basis on which it may be relied upon.

Part III · Domain B — Evidence & Justification

Domain Statement

The architecture must be able to represent, evaluate and preserve the grounds on which an object may be believed without conflating evidential quality, justification and operational acceptance.

B-CAP-01 · Evidence Registration and Relationship

Capability statement. The architecture can register evidence and counter-evidence as governed records and relate them explicitly to claims, objects and assessments.

Purpose. Make evidential support, challenge and origin independently inspectable.

Upstream derivation. KF-2002 B1, B2; KF-3001 AP-05; INV-04; INV-06; IC-20.

Scope. Includes evidence and counter-evidence registration; evidence-to-claim and evidence-to-object linkage; evidence classification (support, challenge, context); evidence provenance; evidence availability status. Excludes quality evaluation (B-CAP-02); justification assembly (B-CAP-03); acceptance; adjudication of the truth of the evidence.

Required behaviours.

• assign evidence-record identity;
• capture evidence origin and type;
• distinguish support, challenge and context;
• relate evidence to specific claims or objects;
• preserve evidence independently from the conclusion drawn from it;
• retain conflicting evidence;
• identify missing or unavailable evidence explicitly.

Principal information objects. Evidence RecordEvidence record — the durable record that a material obligation or decision was discharged; wherever possible emitted by the governed act itself (KF-3004 §5.2). Vocabulary →; Counter-Evidence Record; Evidence-to-Claim Link; Evidence Classification; Evidence Availability Status.

Capability relationships. - Prerequisites: A-CAP-01, A-CAP-02 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-01

Protected invariants. INV-04; INV-06; INV-24.

Operating criticality. Governance-critical — warrant depends on inspectable evidence.

Failure conditions. Evidence embedded but not identifiable; evidence detached from its source; counter-evidence hidden or deleted; support relationship stated without basis; unavailable evidence represented as favourable evidence.

Conformance condition. For each material claim, the architecture can recover the evidence and counter-evidence related to it, their origins, roles and present availability.

B-CAP-02 · Quality Evaluation

Capability statement. The architecture can assess the quality and fitness of a structured object or evidence item against explicit criteria and record the resulting verdict.

Purpose. Determine whether an object is suitable to proceed toward justification.

Upstream derivation. KF-2002 B1; KF-3001 AP-09, AP-16; INV-21; INV-24.

Scope. Includes application of evaluation criteria; assessment of quality, consistency, completeness and confidence; recording of pass, fail, return, pending and indeterminate verdicts; retention of verdicts and reasons. Excludes justification construction (B-CAP-03); acceptance (C-CAP-01); the definition of organisational thresholds, which belong to the applicable governance or implementation profile.

Required behaviours.

• apply defined evaluation criteria;
• preserve criteria and applicable thresholds;
• evaluate quality, consistency, completeness and confidence;
• distinguish pass, fail, return, pending and indeterminate;
• retain all verdicts and reasons;
• route failed or incomplete assessments appropriately;
• prevent unevaluated conditions from appearing as passed.

Principal information objects. Evaluation Criteria Record; Quality Assessment; Evaluation Verdict; Evaluation Exception; Confidence Record.

Capability relationships. - Prerequisites: A-CAP-02, B-CAP-01 - Constrained by: E-CAP-04 - Evidence providers: E-CAP-05 - Provides evidence to: E-CAP-02

Protected invariants. INV-05; INV-21; INV-24.

Operating criticality. Governance-critical — the quality gate precedes justification.

Failure conditions. Undocumented criteria; verdict without reasons; pending assessment treated as passed; low-quality object advanced; evaluation altered after the fact without history.

Conformance condition. For any evaluation, a reviewer can recover the criteria, inputs, evaluator, result, confidence, reasons and disposition.

B-CAP-03 · Justification Construction and Inspection

Capability statement. The architecture can assemble, preserve and expose an inspectable warrant connecting claims to evidence, counter-evidence, rationale and assumptions.

Purpose. Establish why an object may be believed without claiming that justification guarantees truth.

Upstream derivation. KF-2002 B2; KF-3001 AP-05; INV-05; INV-06; IC-09.

Scope. Includes claim-to-evidence linkage; assumptions and rationale; the end-to-end traceability chain; the admission and reliance rationale for parametrically represented capability; preservation of unresolved challenges. Excludes acceptance (C-CAP-01); evidence registration (B-CAP-01); quality evaluation (B-CAP-02); any claim that justification guarantees truth.

Required behaviours.

• relate claims to supporting and defeating evidence;
• record assumptions and rationale;
• preserve unresolved challenges;
• create an end-to-end traceability chain;
• support independent inspection;
• preserve an inspectable admission and reliance rationale for parametric capability;
• prevent acceptance from substituting for justification.

Principal information objects. Justification Record; Assumption Record; Rationale Record; Traceability Chain; Challenge Record.

Capability relationships. - Prerequisites: B-CAP-01, B-CAP-02 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-01 - May trigger: C-CAP-01

Protected invariants. INV-04; INV-05; INV-06; INV-07.

Operating criticality. Governance-critical — justification is the warrant on which reliance rests.

Failure conditions. Rationale unsupported; assumptions hidden; counter-evidence omitted; traceability incomplete; accepted status treated as epistemic proof; modality opacity used as an exemption from warrant.

Conformance condition. An independent reviewer can reconstruct the material reasons for and against belief, identify the assumptions and trace each material claim to its evidential basis.

B-CAP-04 · Epistemic Status Management

Capability statement. The architecture can represent and maintain the epistemic standing of an object independently from its lifecycle, release and acceptance states.

Purpose. Preserve uncertainty, dispute and evidential weakness even where operational reliance is permitted.

Upstream derivation. KF-2002 B1, B2, C1; KF-3001 AP-04, AP-05; INV-03; INV-07; IC-09.

Scope. Includes representation of epistemic conditions from unassessed through insufficiently supported; confidence and uncertainty; contestation; attributable status-change events; prior epistemic states. Excludes lifecycle state (C-CAP-08); acceptance (C-CAP-01); release (C-CAP-05).

Required behaviours.

• represent unassessed, quality-assessed, warrant-established, contested, warrant-weakened and insufficiently supported conditions;
• preserve confidence and uncertainty;
• record unresolved challenges;
• distinguish epistemic status from acceptance;
• update status only through attributable evidence or assessment events;
• preserve prior epistemic states.

Principal information objects. Epistemic Status Record; Confidence Record; Contestation Record; Epistemic Status Change Record.

Capability relationships. - Prerequisites: B-CAP-01, B-CAP-02, B-CAP-03 - Collaborates with: C-CAP-01 - Evidence providers: E-CAP-01

Protected invariants. INV-03; INV-06; INV-07; INV-14.

Operating criticality. Governance-critical — protects the separation of epistemic standing from acceptance.

Failure conditions. Acceptance overwrites evidential weakness; uncertainty reduced without evidence; dispute removed without disposition; lifecycle state used as proxy for epistemic status.

Conformance condition. The architecture can show an object’s present and historical epistemic standing separately from whether it is accepted, released or operationally active.

Part IV · Domain C — Operational Governance

Domain Statement

The architecture must be able to control authority, stewardship, review, versioning, release, change, dependency and transition throughout the operational life of an object. Version, acceptance and release are kept as distinct capabilities because they occur at different points and are governed by different obligations.

C-CAP-01 · Authority and Acceptance Management

Capability statement. The architecture can record and govern the decision by which an identified authority permits reliance upon a justified object.

Purpose. Separate epistemic warrant from institutional permission to rely.

Upstream derivation. KF-2002 C1; KF-3001 AP-06, AP-08; INV-05, INV-08, INV-09, INV-17; IC-09, IC-13.

Scope. Includes acceptance, provisional-acceptance and refusal decisions; authority identification and scope verification; the scope, conditions and duration of reliance; decision rationale. Excludes justification construction (B-CAP-03); permission assignment (E-CAP-03); version creation (C-CAP-04); release designation (C-CAP-05); stewardship (C-CAP-02).

Required behaviours.

• identify the accepting authority or accountable body;
• verify that the authority’s mandate, scope and effective period apply to the decision;
• record acceptance, provisional acceptance or refusal;
• define scope, conditions and duration of reliance;
• preserve decision rationale;
• prevent acceptance where mandatory prerequisites are absent;
• route refusal or conditional acceptance appropriately.

Principal information objects. Acceptance Record; Refusal Record; Scope-of-Reliance Record; Authority Assignment Reference; Acceptance Condition Record.

Capability relationships. - Prerequisites: B-CAP-03, B-CAP-04, E-CAP-03 - Collaborates with: C-CAP-08 - Evidence providers: E-CAP-01 - May trigger: C-CAP-05, C-CAP-08

Protected invariants. INV-05; INV-08; INV-09; INV-17; INV-24.

Operating criticality. Governance-critical; normally fail-closed — no acceptance without an applicable authority.

Failure conditions. Acceptance without an identified applicable authority; acceptance substituting for justification; technical permission mistaken for acceptance authority; acceptance where mandatory prerequisites are absent; refusal neither routed nor recorded.

Conformance condition. Every accepted object carries a decision attributable to an authority or accountable body whose mandate, scope and effective period were applicable, together with the reliance scope, conditions, date and supporting justification.

C-CAP-02 · Stewardship and Responsibility Management

Capability statement. The architecture can assign, maintain and transfer stewardship and responsibility for an operational object.

Purpose. Ensure sustained human accountability throughout operational life.

Upstream derivation. KF-2002 C2; KF-3001 AP-08; INV-09; INV-10; INV-11.

Scope. Includes steward assignment and transfer; identification of accountable roles; stewardship history; the mandate and membership of an accountable body where used. Excludes acceptance decisions (C-CAP-01); review scheduling (C-CAP-03); access-permission assignment (E-CAP-03).

Required behaviours.

• assign a steward before operational release;
• identify accountable roles;
• transfer stewardship without loss of history;
• prevent ownerless operational state;
• distinguish service execution from human accountability;
• preserve mandate and membership where an accountable body is used.

Principal information objects. Stewardship Assignment; Responsibility Record; Stewardship History; Accountable Body Record.

Capability relationships. - Prerequisites: A-CAP-01 - Collaborates with: C-CAP-08 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-01

Protected invariants. INV-09; INV-10; INV-11.

Operating criticality. Governance-critical — no operational object may be ownerless.

Failure conditions. Ownerless operational object; stewardship transfer that loses history; service execution mistaken for accountability; accountable body without recoverable mandate or membership.

Conformance condition. For every operational object and material governance decision, the architecture can identify the responsible steward and applicable human authority or accountable body.

C-CAP-03 · Review and Compliance Management

Capability statement. The architecture can schedule, execute and record reviews and determine whether standing governance conditions remain satisfied.

Purpose. Preserve legitimacy as evidence, policy and context change.

Review determines whether the object’s warrant, utility and governance standing remain adequate. Compliance determines whether applicable formal obligations are satisfied. A review may include compliance evaluation, but one does not substitute for the other.

Upstream derivation. KF-2002 C2; KF-3001 AP-07, AP-16; INV-10, INV-18, INV-21, INV-24.

Scope. Includes review scheduling; due and overdue detection; evaluation of applicable policy and governance requirements; recording of review outcomes, compliance findings and exceptions; triggering of suspension, evolution or retirement. Excludes the transition execution itself (C-CAP-08); acceptance (C-CAP-01); the definition of external policy.

Required behaviours.

• establish review cycles;
• detect due and overdue reviews;
• evaluate applicable policy and governance requirements;
• record review outcomes, compliance assessments and exceptions;
• trigger suspension, evolution or retirement;
• prevent expired governance conditions from remaining silently valid.

Principal information objects. Review Schedule; Review Record; Compliance Assessment; Compliance Finding; Governance Exception; Review Trigger.

Capability relationships. - Prerequisites: C-CAP-02 - Collaborates with: C-CAP-08 - Constrained by: E-CAP-04 - May trigger: C-CAP-06, C-CAP-08 - Provides evidence to: E-CAP-02

Protected invariants. INV-10; INV-18; INV-21; INV-24.

Operating criticality. Governance-critical; recoverable within a defined period — a late review is bounded and must be visible as overdue.

Failure conditions. Expired governance condition remaining silently valid; overdue review undetected; compliance breach unrecorded; review outcome without disposition.

Conformance condition. The architecture can establish whether every operational object has a valid steward, review status and applicable governance conditions in force.

C-CAP-04 · Version Management

Capability statement. The architecture can create, preserve and resolve immutable versions of an Operational Knowledge Object without altering its enduring identity.

Purpose. Preserve every state of represented content and warrant as an immutable, recoverable version, distinct from acceptance and release. A version must exist before an object can be evaluated, justified, accepted or released; version creation is therefore prior to, not consequent on, acceptance.

Upstream derivation. KF-2002 C2, C3; KF-3001 AP-04, AP-11; INV-03, INV-12, INV-14; IC-06.

Scope. Includes creation of candidate and governed versions; preservation of prior versions; the version-to-identity relation; predecessor and successor identification; correction and supersession relationships; the distinction of version state from acceptance and release state. Excludes the acceptance decision (C-CAP-01); release designation (C-CAP-05); lineage and evolution operations (C-CAP-06).

Required behaviours.

• create candidate and governed versions;
• preserve prior versions;
• relate versions to their object identity;
• prevent overwrite;
• identify predecessor and successor versions;
• preserve correction and supersession relationships;
• distinguish version state from acceptance and release state.

Principal information objects. Version Record; Version State; Predecessor–Successor Link; Correction Record.

Capability relationships. - Prerequisites: A-CAP-01, A-CAP-02 - Collaborates with: E-CAP-05 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-01

Protected invariants. INV-03; INV-12; INV-14; and constraint IC-06.

Operating criticality. Governance-critical; fail-closed — a prior version is never overwritten.

Failure conditions. Version overwritten; version detached from object identity; predecessor or successor relationship lost; version state conflated with release state.

Conformance condition. For any object, a reviewer can enumerate its immutable versions, their order, and their correction and supersession relationships, distinct from whether any version is accepted or released.

C-CAP-05 · Release Management

Capability statement. The architecture can designate an accepted version as eligible for a defined scope and period of operational reliance.

Purpose. Separate controlled operational release from both version creation and acceptance, so that creating a version does not release it and accepting a version does not automatically make every successor released.

Upstream derivation. KF-2002 C2; KF-3001 AP-04, AP-06; INV-05, INV-17; IC-08.

Scope. Includes verification of acceptance; binding of release to a specific immutable version; release scope and effective period; prevention of automatic release inheritance; withdrawal, suspension and supersession of releases; release history. Excludes version creation (C-CAP-04); the acceptance decision (C-CAP-01); actionable-form release (D-CAP-01).

Required behaviours.

• verify acceptance;
• bind release to a specific immutable version;
• define release scope and effective period;
• prevent automatic inheritance of release by a new version;
• withdraw, suspend or supersede releases;
• preserve release history.

Principal information objects. Release Record; Release Scope; Effective Period; Withdrawal Record; Supersession Record.

Capability relationships. - Prerequisites: C-CAP-01, C-CAP-04 - Collaborates with: C-CAP-08 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-05

Protected invariants. INV-05; INV-17; and constraint IC-08.

Operating criticality. Governance-critical; normally fail-closed — no release without a bound, accepted version.

Failure conditions. Release without acceptance; a new version inheriting release automatically; release not bound to a specific version; withdrawal that deletes history.

Conformance condition. For every released form, the architecture can identify the immutable version released, its acceptance basis, scope, effective period and predecessor or successor releases.

C-CAP-06 · Lineage and Evolution Management

Capability statement. The architecture can govern amendment, branching, consolidation, supersession and reactivation while preserving history and requiring renewed warrant.

Purpose. Make semantic change a controlled and attributable operation.

Upstream derivation. KF-2002 C3; KF-3001 AP-10, AP-11; INV-12, INV-13, INV-14, INV-16; IC-06, IC-07.

Scope. Includes change triggers and rationale; creation of successor versions or objects; preservation of branch, consolidation and supersession lineage; correction history; routing changed states through evaluation, justification and acceptance. Excludes version-record mechanics (C-CAP-04); dependency impact (C-CAP-07); the acceptance decision itself (C-CAP-01).

Required behaviours.

• record change triggers and rationale;
• create successor versions or objects appropriately;
• preserve branch, consolidation and supersession lineage;
• distinguish object evolution from object replacement;
• return changed states through evaluation, justification and acceptance;
• preserve correction history;
• prevent silent mutation.

Principal information objects. Change Record; Lineage Record; Branch Record; Consolidation Record; Correction Record; Reactivation Proposal.

Capability relationships. - Prerequisites: C-CAP-04 - Collaborates with: C-CAP-07, C-CAP-08 - Evidence providers: E-CAP-01 - May trigger: B-CAP-02, B-CAP-03, C-CAP-01

Protected invariants. INV-12; INV-13; INV-14; INV-16; and constraints IC-06, IC-07.

Operating criticality. Governance-critical — silent mutation and lineage loss are the failures it exists to prevent.

Failure conditions. Silent mutation; lineage lost on branch or merge; predecessor identity mutated; change without renewed warrant; correction that overwrites the corrected record.

Conformance condition. For any current state, a reviewer can reconstruct its predecessors, changes, rationales, responsible actors and renewed evaluation, justification and acceptance.

C-CAP-07 · Dependency Impact Management

Capability statement. The architecture can identify and disposition objects, actionable forms and applications affected by a proposed or completed change.

Purpose. Prevent locally correct change from silently invalidating dependent knowledge.

Upstream derivation. KF-2002 C3; KF-3001 AP-12; INV-13, INV-15, INV-18, INV-24.

Scope. Includes representation of material dependencies; determination of impacted dependants; impact classification; disposition as revalidation, evolution, suspension or no-action; preservation of impact decisions. Excludes the change execution (C-CAP-06); the application itself (D-CAP-02); discovery of dependencies beyond governed objects.

Required behaviours.

• represent material dependencies;
• determine impacted dependants;
• classify impact;
• require revalidation, evolution, suspension or no-action disposition;
• preserve impact decisions;
• prevent return to operational use where material dependencies remain undispositioned.

Principal information objects. Dependency Record; Dependency Impact Record; Revalidation Requirement; Dependency Disposition Record; Suspension Recommendation.

Capability relationships. - Prerequisites: A-CAP-03 - Collaborates with: C-CAP-06 - May trigger: C-CAP-06, C-CAP-08

Protected invariants. INV-13; INV-15; INV-18; INV-24.

Operating criticality. Governance-critical; normally fail-closed — a changed object does not return to use with undispositioned dependants.

Failure conditions. Dependants unidentified; a changed object returning to use with undispositioned dependants; impact decision unrecorded; material dependency representation absent.

Conformance condition. For every material change, the architecture can identify affected dependants and show their recorded disposition before the changed object returns to operational use.

C-CAP-08 · Event, Gate and Transition Management

Capability statement. The architecture can register lifecycle events, evaluate gates and execute attributable state transitions as one governed operation.

Purpose. Preserve the controlled movement of objects through the lifecycle. Operational control determines whether a transition may execute; independent assurance (E-CAP-02) later determines whether the control operated correctly, and is therefore an evidence consumer, not a prerequisite of the transition.

Upstream derivation. KF-2001 lifecycle states, events, gates and transitions; KF-3001 AP-09, AP-16; INV-08, INV-09, INV-10, INV-14, INV-24; IC-01, IC-02.

Scope. Includes event registration; gate identification and eligibility evaluation; transactional binding of gate decision and transition; separate attribution of execution and authority; forward, return, suspension and retirement paths. Excludes the definition of gate criteria (KF-3005); the content of the acceptance decision (C-CAP-01); dependency disposition (C-CAP-07).

Required behaviours.

• register triggering events;
• determine applicable current and proposed states;
• identify the required gate;
• evaluate transition eligibility;
• bind Gate Decision and Transition Records transactionally under one transition identifier;
• attribute execution and accountable authority separately;
• support forward, return, suspension and retirement paths;
• prevent invalid or indeterminate gates from silently passing.

Principal information objects. Event Record; Gate Decision Record; Transition Record; Transition Warrant; Transition Status.

Capability relationships. - Prerequisites: applicable gate criteria and current state - Collaborates with: C-CAP-01, C-CAP-03, C-CAP-05, C-CAP-06, C-CAP-07, D-CAP-04 - Constrained by: E-CAP-03, E-CAP-04 - Evidence providers: E-CAP-01, E-CAP-05 - Provides evidence to: E-CAP-02

Protected invariants. INV-08; INV-09; INV-10; INV-14; INV-24.

Operating criticality. Governance-critical; normally fail-closed — an indeterminate or unavailable gate does not silently pass.

Failure conditions. Lifecycle state changed outside this capability; gate decision and transition not atomically bound; indeterminate gate silently passing; transition unattributed.

Conformance condition. For every transition, the architecture can recover the event, prior state, proposed state, applicable gate, gate result, execution actor, accountable authority and transition outcome under one transition identifier.

Part V · Domain D — Operational Use

Domain Statement

The architecture must be able to derive usable forms from accepted objects, govern their application and return application outcomes to the lifecycle.

D-CAP-01 · Actionable Form Derivation and Release

Capability statement. The architecture can derive actionable forms from governed objects and control when those forms become eligible for operational use.

Purpose. Convert represented knowledge into usable forms without severing warrant. Form-level release governed here is distinct from object-level release (C-CAP-05).

Upstream derivation. KF-2002 D1; KF-3001 AP-05; INV-17, INV-18; IC-10, IC-12.

Scope. Includes derivation of actionable forms; the provisional-versus-released distinction; source-version linkage; warrant and acceptance linkage of released forms; withdrawal or replacement on source change. Excludes application and use (D-CAP-02); acceptance (C-CAP-01); the object’s own versioning (C-CAP-04).

Required behaviours.

• derive rules, playbooks, procedures, prompts, patterns, models and other actionable forms;
• distinguish provisional form from released form;
• link each form to its source object version;
• link released forms to justification and acceptance;
• prevent provisional forms from operational use;
• identify forms affected by source change;
• withdraw or replace forms when source standing changes.

Principal information objects. Actionable Form; Derivation Record; Warrant Linkage; Form Release Record; Form Status.

Capability relationships. - Prerequisites: C-CAP-01, C-CAP-04 - Collaborates with: C-CAP-05 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-01

Protected invariants. INV-17; INV-18; and constraints IC-10, IC-12.

Operating criticality. Operationally critical; normally fail-closed for release — a form is not made usable without a warrant linkage.

Failure conditions. Form severed from warrant; provisional form used operationally; form not linked to a source version; stale form used after source change.

Conformance condition. Every operationally eligible actionable form traces to an accepted object version and carries an inspectable release and warrant linkage.

D-CAP-02 · Controlled Application and Explanation

Capability statement. The architecture can govern material use of actionable forms and preserve an explanation appropriate to the modality, risk and decision context.

Purpose. Ensure that use remains authorised, traceable and explainable.

Upstream derivation. KF-2002 D2; KF-3001 AP-13; INV-17, INV-18, INV-20; IC-11, IC-12, IC-13.

Scope. Includes eligibility verification; recording of material application context; identification of human and computational participants; preservation of the input-to-result path; modality-appropriate explanation; enforcement of disclosure and use restrictions. Excludes outcome capture (D-CAP-03); the form derivation (D-CAP-01); user-interface design.

Required behaviours.

• verify object, version, form, release and governance eligibility before use;
• record material application context;
• identify human and computational participants;
• preserve relevant input-to-result path;
• provide explanation adequate to the applicable modality, materialityMateriality — the degree to which an object, claim, decision or transition may affect consequential action, reliance, obligation, exposure, representation or preservation (KF-2003). Vocabulary →, risk and decision context;
• detect use of invalid or withdrawn forms;
• enforce disclosure and use restrictions.

Principal information objects. Application Record; Use Context Record; Eligibility Decision; Explanation Record; Application Participant Record.

Capability relationships. - Prerequisites: D-CAP-01 - Collaborates with: C-CAP-08 - Constrained by: C-CAP-03, E-CAP-03 - Evidence providers: E-CAP-01 - May trigger: D-CAP-03

Protected invariants. INV-17; INV-18; INV-20; and constraints IC-11, IC-12, IC-13.

Operating criticality. Operationally critical; normally fail-closed for use — an ineligible object is not applied.

Failure conditions. Use without an eligibility check; application for which no explanation adequate to the applicable modality, materiality, risk and decision context can be produced; use of a withdrawn or invalid form; disclosure restriction bypassed; use detached from warrant.

Conformance condition. For each material application, the architecture can identify what was used, why it was eligible, who or what participated, the context of use, the resulting action or recommendation, and an explanation proportionate to the applicable risk and modality.

D-CAP-03 · Outcome and Feedback Capture

Capability statement. The architecture can capture application outcomes and return them as governed evidence, review triggers or change signals.

Purpose. Close the lifecycle from operational use back to evaluation and evolution.

Upstream derivation. KF-2002 D2; KF-3001 AP-11; INV-06, INV-19, INV-24.

Scope. Includes attachment of outcomes to application and object version; the distinction of observation from interpretation; preservation of adverse, contradictory and null outcomes; materiality assessment under an applicable profile; assignment of a disposition; aggregation preserving individual provenance. Excludes the application itself (D-CAP-02); evolution execution (C-CAP-06); the definition of materiality thresholds, which belong to the applicable profile.

Required behaviours.

• attach outcomes to application and object version;
• distinguish observed result from interpretation;
• preserve adverse, contradictory and null outcomes;
• assess outcome materiality under an applicable profile;
• assign a disposition — no action, additional observation, investigation, temporary restriction, suspension, review, evolution, retirement or continued use;
• raise the corresponding lifecycle trigger where required;
• aggregate outcomes while preserving individual provenance.

Principal information objects. Outcome Record; Interpretation Record; Feedback Record; Materiality Assessment; Disposition Record; Lifecycle Trigger.

Capability relationships. - Prerequisites: D-CAP-02 - Evidence providers: E-CAP-01 - May trigger: C-CAP-03, C-CAP-06, C-CAP-08

Protected invariants. INV-06; INV-19; INV-24.

Operating criticality. Operationally critical; recoverable within a defined period — outcome capture may lag briefly, provided the gap is visible and bounded.

Failure conditions. Outcomes not captured; observation and interpretation conflated; adverse outcomes suppressed; aggregation that erases provenance; outcomes without disposition.

Conformance condition. Every material outcome is traceable to the application, actionable form and object version involved and has a recorded disposition under the applicable governance profile.

D-CAP-04 · Retirement and Historical Preservation

Capability statement. The architecture can conclude operational use of an object while preserving identity, record integrity, lineage and the possibility of governed reactivation.

Purpose. Remove knowledge from active reliance without destroying institutional memory.

Upstream derivation. KF-2002 D3; KF-3001 AP-11; INV-09, INV-13, INV-16, INV-18; IC-04.

Scope. Includes retirement of the Operational Knowledge Object from active operational eligibility; determination and recording of retirement reason and authority; preservation of the full historical record; maintenance of successor and supersession links; retrieval as historical material; governed reactivation. Withdrawal of a particular release or actionable form without retiring the object remains governed by C-CAP-05 and D-CAP-01 respectively; retirement is reserved for the object as a whole. Excludes destructive deletion; the evolution path itself (C-CAP-06); acceptance (C-CAP-01).

Required behaviours.

• determine and record retirement reason;
• identify retirement authority;
• remove the object and its forms from active eligibility;
• preserve the full historical record;
• maintain successor and supersession links;
• support retrieval as historical material;
• permit reactivation only through governed evolution;
• prevent destructive deletion of governed history.

Principal information objects. Retirement Record; Historical Object Record; Preservation Record; Reactivation Request; Successor Link.

Capability relationships. - Prerequisites: A-CAP-01 - Collaborates with: C-CAP-08 - Constrained by: E-CAP-03 - Evidence providers: E-CAP-05 - May trigger: C-CAP-06 (reactivation)

Protected invariants. INV-09; INV-13; INV-16; INV-18; and constraint IC-04.

Operating criticality. Governance-critical — destructive deletion of governed history is prohibited.

Failure conditions. Retirement without a recorded reason or authority; destructive deletion; lineage lost; a retired object remaining operationally usable; reactivation outside governed evolution.

Conformance condition. A retired object cannot be used operationally, but its identity, versions, warrant, governance history, applications, outcomes and lineage remain recoverable.

Part VI · Domain E — Assurance, Protection & Continuity

Domain Statement

The architecture must be able to preserve the provenance, integrity, operating condition and conformance evidence required for Domains A–D to remain trustworthy across time and computational modality. Domain E preserves and evaluates governed context; it does not author or alter substantive content, nor independently authorise transitions.

E-CAP-01 · Provenance and End-to-End Traceability

Capability statement. The architecture can preserve origin, derivation, custody, attribution and relationship traceability across every material object, record, transition and application.

Purpose. Make current states and historical change reconstructable.

Upstream derivation. KF-2002 A1, A2, B2, C2, C3, D1; KF-3001 AP-11, AP-12; INV-02, INV-04, INV-08, INV-13, INV-17, INV-19, INV-24; IC-20.

Scope. Includes preservation of source origin; why-, where- and how-provenance; traceability across representations, changes, actionable forms, applications and outcomes; provenance across modality hand-offs; explicit identification of provenance gaps. Excludes substantive content (Domains A–D); access control (E-CAP-03); the authorising of transitions (C-CAP-08).

Required behaviours.

• preserve source origin;
• capture why-, where- and how-provenance where applicable;
• trace representations to sources and objects;
• trace changes to actors, evidence and events;
• trace actionable forms to warrant;
• trace applications and outcomes to the forms used;
• preserve provenance across human, symbolic, parametric and hybrid hand-offs;
• identify incomplete or unavailable provenance explicitly.

Principal information objects. Provenance Record; Custody Record; Derivation Link; Attribution Link; Traceability Path; Provenance Gap Record.

Capability relationships. - Prerequisites: A-CAP-01 - Constrained by: E-CAP-03 - Provides evidence to: all capabilities (E-CAP-01 is a primary evidence provider across the model)

Protected invariants. INV-02; INV-04; INV-08; INV-13; INV-17; INV-19; INV-24.

Operating criticality. Governance-critical and conformance-critical; fail-closed at hand-offs — a material hand-off that cannot preserve provenance is not silently completed.

Failure conditions. Broken lineage; provenance regenerated rather than carried through a hand-off; a provenance gap concealed rather than represented; attribution lost at a hand-off.

Conformance condition. For a representative material outcome, the architecture can reconstruct the path from source and object creation through evaluation, acceptance, operationalisation, use and outcome, while exposing any known provenance gaps.

E-CAP-02 · Conformance and Independent Assurance

Capability statement. The architecture can determine and demonstrate whether required capabilities, invariants, gates, controls and interaction constraints are satisfied.

Purpose. Prevent architectural compliance from depending solely on structural resemblance or self-assertion. E-CAP-02 receives evidence from all capabilities and may raise findings, exceptions, suspension recommendations or corrective-action triggers. It does not participate in the substantive decision or service action it later assesses, and is never an operational prerequisite of the operations it evaluates.

Upstream derivation. KF-3001 Part VI; KF-3001 AP-03; INV-21, INV-22, INV-23, INV-24; IC-17, IC-18.

Scope. Includes inspection of required records and control evidence; invariant and prohibited-path testing; cross-service reconciliation; recording of findings, exceptions and violations; the distinction of conformance, variation, exception and non-conformance. Excludes altering the records under examination; authorising transitions; acting as sole judge of its own outputs; participating as a prerequisite in the operations it assesses.

Required behaviours.

• inspect required records and control evidence;
• test invariant conditions;
• test prohibited paths;
• reconcile evidence across services;
• preserve assurance independence;
• record findings, exceptions and violations;
• distinguish conformance, variation, exception and non-conformance;
• avoid altering records under examination.

Principal information objects. Conformance Assessment; Invariant Test Result; Constraint Test Result; Assurance Finding; Non-Conformance Record; Exception Reference.

Capability relationships. - Evidence consumers: receives evidence from all capabilities - May trigger: C-CAP-08 (via suspension recommendation), E-CAP-04 - Constrained by: its own read-only and independence rules (IC-17, IC-18)

Protected invariants. INV-21; INV-22; INV-23; INV-24.

Operating criticality. Conformance-critical but not transaction-blocking — assurance must exist and be independent, but its unavailability does not by itself halt governed operations; it renders them unproven until reconciled.

Failure conditions. Self-certification; assurance that alters the records examined; non-conformance recorded as a mere exception; an indeterminate condition treated as a pass; assurance made a prerequisite of the operation it audits.

Conformance condition. The architecture can produce independently inspectable evidence for every required capability and report unmet, indeterminate or violated conditions without modifying the evidence assessed.

E-CAP-03 · Access, Authority Boundary and Integrity Protection

Capability statement. The architecture can restrict access and material action according to assigned permissions while preserving the distinction between permission and authority.

Purpose. Protect governed records and operations against unauthorised access, alteration or disclosure.

Upstream derivation. KF-3000 §1 access, disclosure and integrity obligations; KF-3001 AP-06; INV-08, INV-09, INV-11, INV-23; IC-13, IC-14, IC-15, IC-16.

Scope. Includes actor and service identification; permission assignment and revocation; the permission-versus-authority distinction; record-integrity protection; disclosure and use restriction; administrative-action recording; permission and authority history. Excludes acceptance-authority decisions (C-CAP-01); specific security technologies (KF-4000); the content of the governance decision.

Required behaviours.

• identify actors and services;
• assign and revoke permissions;
• distinguish technical access from governance authority;
• enforce view, create, amend, accept, release, suspend and retire permissions;
• protect record integrity;
• enforce disclosure and use restrictions;
• record material administrative action;
• preserve permission and authority history.

Principal information objects. Access Policy; Permission Assignment; Authority Assignment Reference; Disclosure Constraint; Integrity Status; Administrative Action Record.

Capability relationships. - Collaborates with: C-CAP-02 - Constrains: all capabilities performing a material action - Evidence providers: E-CAP-05

Protected invariants. INV-08; INV-09; INV-11; INV-23; and constraints IC-13, IC-14, IC-15, IC-16.

Operating criticality. Governance-critical; normally fail-closed — an unauthorised material action is refused, not permitted by default.

Failure conditions. Permission mistaken for authority; unauthorised alteration; record integrity compromised; material administrative action unrecorded; disclosure restriction bypassed.

Conformance condition. For every material action, the architecture can demonstrate that the actor possessed the required permission and, where applicable, that a separate valid authority decision existed.

E-CAP-04 · Operating Condition, Exception and Degraded-State Management

Capability statement. The architecture can represent normal, failed, pending, indeterminate and degraded conditions explicitly and govern their consequences.

Purpose. Prevent absent evidence, failed controls or unavailable services from appearing as successful operation.

Upstream derivation. KF-3001 AP-16; INV-10, INV-18, INV-21, INV-24; IC-19.

Scope. Includes the distinction of passed, failed, pending and indeterminate conditions; representation of service and control degradation; explicit fail-open or fail-closed decision; exception raising, tracking and bounding; compensating controls; corrective triggering. Excludes the corrective transition execution (C-CAP-08); the definition of organisational risk acceptance (governance).

Required behaviours.

• distinguish passed, failed, pending and indeterminate conditions;
• represent service or control degradation;
• determine fail-open or fail-closed behaviour explicitly;
• prevent silent success;
• raise and track exceptions;
• bound duration and scope of authorised exceptions;
• preserve compensating controls;
• trigger suspension or corrective action where required.

Principal information objects. Operating Condition Record; Degradation Record; Exception Record; Compensating Control Record; Recovery Record; Failure Disposition Record.

Capability relationships. - Collaborates with: C-CAP-08 - May trigger: C-CAP-08 (suspension or corrective action) - Provides evidence to: E-CAP-02

Protected invariants. INV-10; INV-18; INV-21; INV-24; and constraint IC-19.

Operating criticality. Conformance-critical and governance-critical — it is the capability that determines fail-safe behaviour, so its own degradation defaults to fail-closed.

Failure conditions. Silent success; an unavailable service presumed available; an exception without bound or expiry; a degraded state concealed; missing evidence read as a pass.

Conformance condition. When a required condition cannot be evaluated or a service is degraded, the architecture records the condition explicitly and applies the predefined operational consequence rather than treating it as satisfied.

E-CAP-05 · Temporal and Historical Continuity

Capability statement. The architecture can preserve the temporal meaning, sequence and authenticity of governed records and states across time.

Purpose. Maintain trust where events, records and effective conditions occur at different times.

Upstream derivation. KF-2002 C2, D3; KF-3001 AP-11; INV-04, INV-12, INV-13, INV-14, INV-16; IC-21, IC-22.

Scope. Includes preservation of recorded, effective and event time; sequencing of transitions and decisions; retention of superseded and corrected records; authenticity across custody and format change; as-of historical reconstruction; retention and disposition. Excludes the version mechanics (C-CAP-04); storage technology; substantive content.

Required behaviours.

• preserve recorded time;
• preserve effective time;
• preserve event time where distinct;
• sequence transitions and decisions;
• retain superseded and corrected records;
• preserve authenticity through custody and format change;
• support historical reconstruction as of a specified time;
• enforce retention and disposition conditions.

Principal information objects. Temporal Metadata Record; Effective Period; Event-Time Record; Custody History; Retention Condition; Historical Reconstruction Result.

Capability relationships. - Collaborates with: C-CAP-04, C-CAP-06 - Evidence providers: E-CAP-01 - Provides evidence to: E-CAP-02

Protected invariants. INV-04; INV-12; INV-13; INV-14; INV-16; and constraints IC-21, IC-22.

Operating criticality. Governance-critical; recoverable with bounded manual control — temporal reconstruction may require manual assembly for a bounded period, but must never rely on overwritten records.

Failure conditions. Temporal semantics collapsed; effective time lost; as-of reconstruction relying on overwritten current records; authenticity broken across a format change; retention condition unenforced.

Conformance condition. The architecture can reconstruct the object’s represented content, warrant, acceptance, governance and operational state at a specified historical point without relying on overwritten current records.

Part VII · Capability Relationships

6. Principal Eligibility Progression

The principal eligibility progression follows the governed life of an object from registration to retirement or evolution:

A-CAP-01 Object Registration
        ↓
A-CAP-02 Structured Representation
        ↓
C-CAP-04 Version Management
        ↓
B-CAP-01 Evidence Registration
        ↓
B-CAP-02 Quality Evaluation
        ↓
B-CAP-03 Justification Construction
        ↓
B-CAP-04 Epistemic Status Management
        ↓
C-CAP-01 Authority and Acceptance
        ↓
C-CAP-02 Stewardship Assignment
        ↓
C-CAP-05 Release Management
        ↓
D-CAP-01 Actionable Form Derivation and Release
        ↓
D-CAP-02 Controlled Application
        ↓
D-CAP-03 Outcome and Feedback
        ↓
C-CAP-06 Evolution   or   D-CAP-04 Retirement

This represents the principal eligibility progression of an object. It is neither a complete lifecycle diagram nor a mandatory procedural workflow. C-CAP-08 governs every state transition along the progression, and the Domain E capabilities — provenance, conformance, access and integrity, operating condition, and temporal continuity — operate throughout rather than at any single point.

7. Critical Capability Relationships

Relationships are typed. The most consequential are:

No relationship in this table is a mutual prerequisite. Where two capabilities appear to depend on one another — acceptance and transition, or evolution and dependency impact — the relationship is collaboration within one governed operation, not circular prerequisite.

8. Prohibited Capability Substitution

The following substitutions are not permitted: discovery may not substitute for provenance; evaluation may not substitute for justification; justification may not substitute for acceptance; acceptance may not substitute for release; version creation may not substitute for release; permission may not substitute for authority; audit logging may not substitute for accountability; explainability may not substitute for evidential warrant; retention may not substitute for historical authenticity; model confidence may not substitute for epistemic status; and service availability may not be presumed when operating condition is unknown.

Part VIII · Capability Completeness

9. Practice-to-Capability Crosswalk

Domain E supports every practice.

10. Invariant-to-Capability Crosswalk (family level)

11. Capability Coverage Test

The model is complete when: every KF-2002 practice maps to at least one principal capability; every mandatory KF-2002 artefact has a capability responsible for its creation or maintenance; every KF-3001 invariant is protected by at least one capability (demonstrated individually in Appendix A); every KF-3001 interaction constraint is enforceable through the capabilities in Appendix B; every capability has an upstream derivation; every capability has at least one independently observable conformance condition; no capability exists solely because a familiar technology category suggests it; and no upstream obligation remains unsupported.

Part IX · Capability Conformance

12. Capability Conformance

A capability is conformant when an implementation demonstrates that all required behaviours are realised; all principal information objects can be produced, maintained and retrieved; relationships are satisfied; protected invariants remain true whenever their scope applies; failure and indeterminate conditions are visible; the stated conformance condition can be demonstrated; and no prohibited substitution is used to claim satisfaction.

Capability conformance may be assessed individually for diagnostic purposes, but architectural conformance is systemic. A capability cannot be declared conformant where an unsatisfied prerequisite or collaborating capability prevents its required behaviours or protected invariants from being realised. Conformance is not a component-by-component certification.

13. Capability Evidence

Evidence may include representative end-to-end lifecycle cases; information-object inspection; invariant tests; prohibited-path tests; authority and permission checks; historical reconstruction; dependency-impact tests; degraded-state tests; cross-service reconciliation; and independent assurance results. Technology features or vendor claims are not, by themselves, evidence of capability conformance.

14. Capability Conformance and Capability Maturity

Capability conformance is not the same as capability maturity, and the two are assessed separately. A conforming capability may exhibit different degrees of automation, scale, latency, usability, coverage, reliability, modality support and assurance independence. A manually maintained stewardship register may conform to C-CAP-02 while being operationally immature; a sophisticated AI governance platform may be non-conforming if it silently passes indeterminate evidence or collapses acceptance into model confidence. Maturity does not compensate for an absent required behaviour or a violated invariant.

Part X · Appendices

Appendix A · Invariant-to-Capability Crosswalk (individual)

Every one of the twenty-four invariants has a principal capability, and no invariant is left without coverage — the check a family-level mapping alone can conceal.

Appendix B · Interaction-Constraint-to-Capability Crosswalk

Every interaction constraint is enforceable through at least one capability, demonstrating enforceability rather than asserting it.

Part XI · Relationship to Subsequent Documents

KF-3003 defines the logical services that expose and coordinate these capabilities; a service may realise several capabilities and a capability may be distributed across several services, and it will carry the typed relationships of §4 and §7 into service collaboration, constraint and evidence contracts. KF-3004 defines the information objects, record classes and relationships named here, and fixes the recorded, effective and event time semantics of Domain E. KF-3005 defines the lifecycle controls and gate logic through which the capabilities operate safely, including the transactional binding of gate decision and transition in C-CAP-08. KF-3008 assigns the authority and accountability of the participants exercising these capabilities (technical permission is assigned by SVC-16). KF-3007 defines the tests and evidence by which capability conformance is demonstrated, including the operating-criticality consequences of unavailability. KF-3009 preserves traceability from Canonical Principle through practice, invariant, capability, service, record, control and implementation.

Closing Statement

The Capability Model defines the complete set of abilities that a governed knowledge architecture must possess. It does not prescribe how those abilities are implemented. It ensures that, whatever form an implementation takes, it can identify and structure knowledge objects, establish and preserve their warrant, govern authority, versioning, release and change, control operational use, learn from outcomes, and demonstrate that these obligations remain satisfied over time.