KF-3001 · Architectural Principles and Invariants

Governing the Design and Behaviour of the Knowledge Foundry Architecture

Reference Architecture · Draft · v0.1 · 33 min read

Canon (KF-1000)
        ↓
Lifecycle and Practices (KF-2001 / KF-2002)
        ↓
Reference Architecture (KF-3000)
        ↓
▸ Architectural Principles and Invariants (KF-3001)
        ↓
Capability, Service and Record Models (KF-3002–KF-3009)
        ↓
Implementation (KF-4000)

Purpose

KF-3000 defines the logical architecture required to realise the Knowledge Foundry methodology. KF-3001 defines the rules that govern the design and behaviour of that architecture.

It establishes:

• the principles that guide architectural decisions;
• the invariants that must remain true across every conforming implementation;
• the constraints that govern interactions among architectural services;
• the mechanisms — architectural decision and conformance — by which those rules are applied and demonstrated.

KF-3001 does not prescribe technologies, products, deployment topologies or implementation procedures. Its purpose is to ensure that different implementations may vary in form without departing from the constitutional and engineering obligations of the Knowledge Foundry.

It does not repeat the Canon, restate the lifecycle, or reproduce the capability catalogue. Its role is narrower and more technical: to translate constitutional commitment and system obligation into durable rules for architectural design.

The Organising Grammar

The document has three primary forms of architectural rule — principle, invariant and interaction constraint — and two mechanisms through which those rules are applied and demonstrated: architectural decision and conformance.

Principle    →  guides design
Invariant    →  defines what must remain true (whenever its scope applies)
Constraint   →  governs interaction so invariants remain true
Decision     →  applies the rules to architectural choices
Conformance  →  demonstrates that the rules are satisfied

A principle permits several conforming designs; an invariant permits none that violate it within its scope; a constraint keeps an invariant true while the system operates; a decision chooses among designs that all satisfy the rules; and conformance shows that all of it holds. Keeping the three rule forms distinct — and separating them from the two mechanisms that apply and demonstrate them — is what stops the architecture drifting into either component compliance (possessing all the named services while letting them bypass one another) or technology compliance (using sophisticated tooling while failing to preserve warrant, authority, provenance or history).

Relationship to Upstream Documents

KF-3001 is derived from the Canonical PrinciplesCanonical Principle — an enduring obligation true of any governed knowledge system, admitted only if it survives the two-question test (KF-1000 Part III). Vocabulary → of KF-1000; the lifecycle stages, gates and invariants of KF-2001; the engineering obligations and governance checkpoints of KF-2002; and the architectural capabilities, services and controls of KF-3000.

The derivation chain is:

Canonical Principle
        ↓
Lifecycle or Practice Obligation
        ↓
Architectural Risk
        ↓
Architectural Principle
        ↓
System Invariant or Interaction Constraint
        ↓
Conformance Evidence

Admission test. A rule belongs in KF-3001 only where violating it could allow an implementation to reproduce the visible structure of KF-3000 while defeating its intended governance, epistemic or historical function. A rule that fails this test is a generic architecture slogan, a restated Canon principle, a data model, a security standard or an implementation guide — and belongs elsewhere.

Part I · Foundations

1. Architectural Rule Types

KF-3001 defines three forms of architectural rule.

1.1 Architectural Principle

A durable design rule that guides architectural choices. A principle constrains design judgement, permits more than one conforming solution, applies across capabilities and services, and is evaluated through the decisions it shapes.

1.2 System Invariant

A condition that must remain true whenever its stated scope and activation conditions apply. An invariant is not satisfied by a one-time check; it is independently testable; and it cannot be waived by implementation convenience. Some invariants are universally active; others apply only when a relevant condition exists (for example, counter-evidence, dependants, or a material application), which its Scope line states.

1.3 Service Interaction Constraint

A rule governing how logical services, actors and records may interact. A constraint protects one or more invariants, assigns or limits architectural responsibility, prevents bypass, silent mutation or collapse of required distinctions, and is enforced through service contracts and controls.

2. Rule Application and Demonstration

The three rule forms are applied to design and shown to hold through two mechanisms. These are not themselves rules.

2.1 Architectural Decision Rule

A rule for selecting between alternative conforming designs. A decision rule makes trade-offs explicit, records the obligations affected, requires justification and approval, and preserves reversibility where practical. Decision rules are specified in Part V.

2.2 Conformance

The demonstration that the principles, invariants and constraints are satisfied: through decisions, mappings and design evidence for principles; through preventive controls, detective checks and tests for invariants; and through service contracts and prohibited-path testing for constraints. Conformance is specified in Part VI. It applies the rules; it is not itself a rule.

3. Relationship Among the Rules

Principle
    guides
Architectural Decision
    produces
System Structure
    constrained by
Interaction Constraints
    preserving
System Invariants

Principles guide design. Invariants define the required condition. Interaction constraints preserve that condition during operation. Decision rules govern choices where several designs can satisfy the same obligations. Conformance demonstrates the result.

4. Rule Specification

Each architectural principle is specified through a Statement, a Rationale, an Upstream basis and its Architectural consequences; where misreading is likely or audit requires it, Prohibited interpretations and Conformance evidence are added. AP-01 is given in full as the exemplar of the complete template.

Each system invariant is specified through its Statement and a compact metadata line giving Scope, the obligation it Protects, its Violation condition, and the services that Uphold it. Required evidence is defined generically in Part VI.

Each interaction constraint is specified through its Statement and a compact metadata line giving the invariant it Protects, the participating services, and the required record or control. Permitted and prohibited interactions are stated within the constraint.

5. Precedence

Where architectural rules appear to conflict, the following precedence applies:

1. Canonical Principles;
2. human-accountability and formally assigned authority;
3. system invariants;
4. lifecycle gates and standing governance conditions;
5. service interaction constraints;
6. architectural principles;
7. local architectural preferences;
8. implementation convenience.

A lower-order rule may not be used to defeat a higher-order obligation.

Applicable law and binding regulation remain external constraints on the architecture and cannot be displaced by this precedence order. KF-3001 governs architectural precedence, not legal conformance.

Part II · Architectural Principles

Family A · Derivation and Sufficiency

AP-01 · Obligation-Derived Architecture

Statement. Every architectural element must be justified by an upstream Canonical, lifecycle, practice, artefact, checkpoint or conformance obligation.

Rationale. The architecture exists to realise the methodology, not to reproduce familiar technology categories.

Upstream basis. KF-1000; KF-2001; KF-2002; the KF-3000 Architectural Admission Test.

Architectural consequences.

• every capability and service carries an upstream basis;
• technology-led components are admitted only after their logical responsibility is established;
• unsupported services are excluded from the reference architecture;
• crosswalks are maintained from principle to implementation.

Prohibited interpretations.

• a technology belongs because it is commonly used;
• architectural completeness means including every enterprise platform category;
• a powerful component may replace an unfulfilled obligation.

Conformance evidence. Principle-to-practice, practice-to-capability and capability-to-service mappings, together with recorded architectural admission decisions.

AP-02 · Necessary and Proportionate Architecture

Statement. The architecture includes every responsibility necessary to discharge its obligations reliably and excludes responsibilities that cannot be justified by an upstream obligation, dependency or assurance need.

Rationale. Architectural economy means proportionate commitment, not minimum component count. A capability that makes several obligations reliable, scalable or independently verifiable is justified even where it maps to no single lifecycle step.

Upstream basis. The method–architecture–implementation separation of KF-1000 and KF-3000.

Architectural consequences.

• capabilities are logical and non-duplicative;
• an enabling or assurance capability is admitted where a dependency or assurance need justifies it;
• implementation concerns remain in KF-4000;
• services may be combined in implementation where their logical responsibilities remain distinguishable.

AP-03 · Conformance over Structural Resemblance

Statement. Architectural conformance is established by discharged obligations and preserved invariants, not by reproducing a particular component diagram.

Rationale. Different implementations may realise the same logical architecture through different arrangements of people, software and models.

Upstream basis. KF-3000 Conformance Architecture.

Architectural consequences.

• conformance is judged against §19 of KF-3000 and the invariants of this document, not against a reference topology;
• two structurally dissimilar implementations may both conform;
• resemblance to the service catalogue is neither necessary nor sufficient for conformance.

Family B · Separation of Concerns

AP-04 · Preserve Semantic Distinctions

Statement. Concepts that carry different governance or epistemic meanings remain logically distinct even where they share a physical representation. At minimum, the architecture distinguishes: object from representation; object from version; version from release; lifecycle state from epistemic status; justification from acceptance; authority from access permission; application from evolution; retirement from deletion; and service responsibility from human accountability.

Rationale. Collapsing these distinctions permits silent bypass of lifecycle and governance obligations.

Upstream basis. KF-3000 §2 (Architectural Unit) and the separation-of-concerns invariant.

Architectural consequences.

• a shared store may hold two concepts only if each remains independently addressable and changeable;
• no operation may alter one distinguished concept as an undocumented side effect of altering another;
• the information model of KF-3004 must preserve each distinction explicitly.

Prohibited interpretations.

• physical co-location is treated as logical identity;
• a single record type is allowed to stand for both a version and a release, or both justification and acceptance.

AP-05 · Separate Knowledge Content from Its Warrant

Statement. The represented content of an object remains distinguishable from the evidence, rationale, assumptions, evaluation and acceptance that warrant its use.

Rationale. Warrant and content change on different schedules and under different authority; fusing them lets a content edit inherit stale warrant, or a warrant change mutate content.

Upstream basis. KF-2002 B1, B2, C1.

Architectural consequences.

• a content change does not silently inherit prior warrant;
• a warrant change can be represented without mutating object identity;
• actionable forms retain traceable links to their warrant.

AP-06 · Separate Execution from Authority

Statement. The ability to perform an operation does not imply authority to approve it.

Rationale. Execution capacity is a technical property; authority is an institutional one. Conflating them lets whatever can act also decide.

Upstream basis. KF-2002 C1, C2; the human-accountability invariant.

Architectural consequences.

• automated execution may support evaluation, transition or release;
• accountable acceptance, stewardship and designated authorisations remain attributable to an authorised person or body;
• access permission does not itself constitute acceptance authority.

Prohibited interpretations.

• holding write permission to a record is read as holding authority to accept, release or retire it.

Family C · Governance and Accountability

AP-07 · Governance Is Continuous

Statement. Governance conditions remain in force throughout operational life rather than being treated as one-time admission checks.

Rationale. Legitimacy decays; a check passed once does not stay passed.

Upstream basis. KF-2002 C2; the Govern standing gate; Canon Principle IV.

Architectural consequences.

• stewardship, review, compliance and acceptance validity are monitored;
• objects may be suspended when standing conditions lapse;
• conformance checks operate continuously or at defined intervals.

AP-08 · Accountability Remains Human

Statement. Every material governance decision remains attributable to an identifiable human authority or accountable body.

Rationale. Computational systems may act, recommend and record, but they cannot absorb institutional accountability.

Definition. An accountable body is a formally constituted human decision-making body whose membership, mandate and decision record are recoverable. A system, an anonymous organisational function or an unminuted committee is not an accountable body.

Upstream basis. KF-1000 Principle III and the human-accountability invariant; KF-2002 C1.

Architectural consequences.

• acceptance, stewardship, release, suspension and retirement each resolve to a human authority or accountable body;
• automation may prepare and execute these decisions but is never their final locus of accountability.

Prohibited interpretations.

• an automated approval step is treated as discharging accountability;
• “the system decided” is accepted as an answer to “who is answerable”.

AP-09 · Control Must Produce Evidence

Statement. Every material governance action and transition leaves an inspectable record sufficient to reconstruct what occurred, why it occurred and under whose authority.

Rationale. A control that leaves no evidence cannot be audited and therefore cannot be trusted to have operated.

Upstream basis. KF-2001 transition rules; KF-2002 artefact obligations.

Architectural consequences.

• controls are evidentiary as well as preventive;
• transitions without records are invalid;
• administrative actions affecting governed state are auditable.

Family D · Continuity, Change and History

AP-10 · Identity Persists Through Change

Statement. Changes to representation, state, warrant or operational form do not silently alter object identity.

Rationale. Identity is the thread on which history is strung; if it moves, lineage breaks.

Upstream basis. KF-2002 A1, C3.

Architectural consequences.

• versions inherit object identity;
• branches and consolidations create new identities with explicit lineage;
• identifiers are never reused.

AP-11 · Change Is Additive to History

Statement. Governed change adds to the historical record rather than replacing it.

Rationale. Trust in a knowledge system is a property of its transitions over time; overwriting the past destroys the evidence of trustworthiness.

Upstream basis. KF-2002 C3, D3; Canon Principle VII.

Architectural consequences.

• prior versions and decisions remain recoverable;
• corrections are appended or versioned;
• retirement preserves lineage;
• rollback does not erase the intervening history.

AP-12 · Dependency-Aware Evolution

Statement. Change to an object is assessed in relation to the objects, actionable forms and applications that depend upon it.

Rationale. A correctly versioned object can still leave its dependants silently inconsistent; provenance is the connective tissue that makes changed states, decisions and lineages reconstructable, and dependency is the reason a local change is never only local.

Upstream basis. KF-2002 C3; KF-L001 Literature Landscape (B04 · Governing Knowledge Change).

Architectural consequences.

• dependencies are represented explicitly;
• impact analysis accompanies material change;
• affected dependants are revalidated, suspended or evolved;
• semantic rollback is not treated as a purely local operation.

Family E · Modality, Implementation and Failure

AP-13 · Modality-Independent Obligation

Statement. Governance and epistemic obligations apply regardless of whether knowledge is represented, interpreted or applied through human judgement, symbolic structures, parametric models or hybrid systems.

Rationale. The computational substrate may change while the epistemic obligations remain (KF-1000 Principle V).

Upstream basis. KF-1000 Principle V (modality independence); KF-L001 (B05 · Foundation Models and the Knowledge Sciences).

Architectural consequences.

• the architecture does not assume all knowledge is explicitly inspectable in the same way;
• explanation and provenance requirements are adapted to modality without being discarded;
• opacity is treated as a constraint to be governed, not an exemption.

Prohibited interpretations.

• a modality that resists inspection is granted an exemption from justification, provenance or explanation;
• interpretability is claimed of a representation that cannot support it.

AP-14 · Logical before Physical Design

Statement. Logical responsibility is defined before selecting physical components, technologies or deployment patterns.

Rationale. Technology chosen ahead of responsibility tends to dictate — and quietly narrow — the responsibilities the architecture will admit.

Upstream basis. The logical-architecture boundary of KF-3000.

Architectural consequences.

• services are specified through responsibilities, inputs, outputs, records and controls;
• one logical service may be distributed across several components;
• several logical services may be combined in one component;
• physical co-location does not erase logical separation.

AP-15 · Humans and Machines Form One Governed System

Statement. Human and computational work are architected as one governed system rather than as separate formal and informal layers.

Rationale. An informal human layer outside the governed system is where provenance, attribution and accountability are lost.

Upstream basis. KF-1000 Principle III; the human–AI governance obligations of the Canon.

Architectural consequences.

• human decisions become governed records;
• machine actions remain attributable;
• hand-offs between people and services preserve provenance;
• informal human approval may not substitute for recorded acceptance.

AP-16 · Explicit Failure and Degraded State

Statement. The architecture represents failure, uncertainty and degraded governance explicitly rather than silently treating absence of evidence as evidence of conformance.

Rationale. A governed system must distinguish “condition satisfied” from “condition not checked”, “evidence unavailable” and “control failed”. These are different states, and collapsing them into an implicit pass is how silent failure enters a system that otherwise looks conformant.

Upstream basis. KF-2002 governance checkpoints; KF-3000 control architecture (detective and corrective controls); the continuous-conformance invariant.

Architectural consequences.

• gate outcomes include pass, fail, pending and indeterminate where appropriate;
• service unavailability does not silently produce approval;
• missing evidence is represented as missing, not as satisfied;
• degraded operation is visible and bounded;
• fail-open and fail-closed behaviour is explicitly decided and recorded.

Prohibited interpretations.

• an unreachable check is treated as a pass;
• absence of a violation record is treated as proof that no violation occurred.

Part III · System Invariants

6. Identity and Representation Invariants

INV-01 · Unique Object Identity

Every 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 → has exactly one immutable identity. Scope: all objects, all lifecycle states. Protects: AP-04, AP-10; Canon Principle I. Violation: an identity resolves to more than one object, an object holds more than one active identity, or an identifier is reused. Upheld by: SVC-01 (with SVC-03).

INV-02 · Representation Traceability

Every governed representation is traceable to the object and version it represents. Scope: all structured representations. Protects: AP-04. Violation: a representation cannot be resolved to a single object and version. Upheld by: SVC-02, SVC-03.

INV-03 · Logical Distinction

Identity, representation, version, release, state, lineage, justification and acceptance remain logically distinguishable. Scope: the whole architecture. Protects: AP-04, AP-05. Violation: two of these collapse such that one cannot be changed or inspected without the other. Upheld by: SVC-01, SVC-02, SVC-06, SVC-07, SVC-09, SVC-10.

7. Evidence and Justification Invariants

INV-04 · Provenance Persistence

Every object retains recorded origin and subsequent provenance throughout its lifecycle. Scope: capture to historical state. Protects: AP-11, AP-12; the provenance invariant. Violation: origin or subsequent provenance is lost or unrecoverable. Upheld by: SVC-03.

INV-05 · Justification before Operational Reliance

No object enters operational reliance without an inspectable justification meeting the applicable gate. Scope: the Justify → Acceptance → Operationalise path. Protects: AP-05; Canon Principle VIII. Violation: an object is relied upon operationally without an inspectable justification meeting its gate. Upheld by: SVC-06, SVC-07, SVC-09.

INV-06 · Counter-Evidence Visibility

Material counter-evidence and unresolved challenge remain attached to the object’s epistemic record. Scope: objects for which material counter-evidence or unresolved challenge exists. Protects: AP-05. Violation: material counter-evidence or unresolved challenge is detached, hidden or overwritten. Upheld by: SVC-04, SVC-06.

INV-07 · Acceptance Does Not Rewrite Epistemic Status

Operational acceptance may define permitted reliance but may not erase uncertainty, disagreement or evidential weakness. Scope: the Acceptance transition and operational life. Protects: AP-05; IC-09. Violation: acceptance overwrites, hides or resets recorded epistemic status. Upheld by: SVC-06, SVC-07.

8. Governance and Accountability Invariants

INV-08 · Attributable Transition

Every lifecycle transition identifies both the service or actor that executed it and, where a governance decision is involved, the human authority or accountable body under whose authority it occurred. Scope: all transitions. Protects: AP-08, AP-09; Canon Principle III. Violation: a transition lacks an identified executor, or a governance-bearing transition lacks an identified human authority or accountable body. Upheld by: SVC-09.

INV-09 · Human Accountability

Every material acceptance, stewardship, release, suspension and retirement decision resolves to an identifiable human authority or a formally constituted accountable body. Scope: all material governance decisions. Protects: AP-08; Canon Principle III and the human-accountability invariant. Violation: such a decision lacks an identifiable human authority or accountable body. Upheld by: SVC-07, SVC-08, SVC-09, SVC-10 and SVC-14, with SVC-16 governing authority and permission assignments.

INV-10 · Standing Governance

Every operational object has valid stewardship, review status and applicable governance conditions in force. Scope: all operational objects. Protects: AP-07; Canon Principles IV and VII. Violation: an operational object is ownerless, unreviewed or out of compliance. Upheld by: SVC-08.

INV-11 · Authorised Change

No governed record or state is materially altered outside authorised service and role boundaries. Scope: all governed records and states. Protects: AP-06, AP-09. Violation: a governed record or state is altered outside its authorised service and role. Upheld by: SVC-16 (with every service).

9. Change and Historical Invariants

INV-12 · Version Preservation

Every prior governed version remains recoverable after change. Scope: all versioned objects. Protects: AP-11; the version-preservation invariant. Violation: a prior version becomes unrecoverable. Upheld by: SVC-10.

INV-13 · Lineage Preservation

Branching, consolidation, supersession, retirement and reactivation preserve explicit predecessor and successor relationships. Scope: all change and closure operations. Protects: AP-10, AP-11. Violation: a predecessor or successor link is lost or made ambiguous. Upheld by: SVC-10 (with SVC-14).

INV-14 · No Silent Mutation

Every material change produces a change, version or correction record. Scope: all governed records and states. Protects: AP-09, AP-11. Violation: a material change leaves no change, version or correction record. Upheld by: SVC-10 (with every service).

INV-15 · Dependency Disposition

No materially changed object returns to operational use until affected dependencies have been identified and dispositioned. Scope: evolution of objects that have dependants. Protects: AP-12. Violation: a materially changed object returns to use with dependants unidentified or undispositioned. Upheld by: SVC-11 (with SVC-09).

INV-16 · Retirement Preserves History

Retirement removes an object from active operational use without destroying its identity, records or lineage. Scope: all retirements. Protects: AP-11; Canon Principle VII. Violation: retirement destroys identity, records or lineage. Upheld by: SVC-14.

10. Operational Invariants

INV-17 · Warranted Actionable Form

Every actionable form traces to a specific object version, justification and valid acceptance-state. Scope: all actionable forms eligible for release or use. Protects: AP-05; IC-12. Violation: a releasable or usable actionable form has no traceable link to version, justification and acceptance. Upheld by: SVC-12.

INV-18 · Governed Application

No suspended, retired, unaccepted or governance-invalid object is used in a governed application. Scope: all governed applications. Protects: AP-07, AP-16. Violation: such an object is used in a governed application. Upheld by: SVC-13. The architecture distinguishes the ways this can fail — prevention failure, detection failure and deliberate override — so that a violation is diagnosable rather than merely flagged.

INV-19 · Outcome Traceability

Every material application outcome can be traced to the object version, actionable form and use context that produced it. Scope: all material applications. Protects: AP-09; the traceable-use invariant. Violation: a material outcome cannot be so traced. Upheld by: SVC-13.

INV-20 · Modality-Appropriate Explainability

Every material application supports an account appropriate to its modality, risk and decision context. Scope: all material applications. Protects: AP-13; Canon Principle IX. Violation: a material application supports no account appropriate to its modality, risk and context. Upheld by: SVC-13.

11. Assurance Invariants

INV-21 · Inspectable Conformance

The architecture can produce evidence showing whether each required capability, gate and invariant is satisfied. Scope: the whole architecture. Protects: AP-09. Violation: the architecture cannot show whether a required capability, gate or invariant holds. Upheld by: SVC-15.

INV-22 · Assurance Independence

A service may not be the sole judge of the validity of the records or controls it produces. Scope: all conformance judgements. Protects: IC-18. Violation: a service certifies its own records or controls with no independent check. Upheld by: SVC-15.

INV-23 · Audit Non-Interference

Assurance and audit operations do not alter the governed records under examination. Scope: all assurance and audit operations. Protects: IC-17. Violation: an assurance or audit operation alters a governed record under examination. Upheld by: SVC-15.

INV-24 · No Silent Success

An unmet, unevaluated or indeterminate required condition is never represented as satisfied. Scope: all required conditions, gates and checks. Protects: AP-16, AP-09. Violation: an unmet, unevaluated or indeterminate condition is represented as satisfied — for example, service unavailability yields approval, or missing evidence is read as a pass. Upheld by: SVC-15 (with SVC-09 for gate outcomes).

Part IV · Service Interaction Constraints

12. State and Transition Constraints

IC-01 · Lifecycle State Authority

Only the Lifecycle and Transition Service may alter the recorded lifecycle state of an object. Other services may request, recommend or trigger a transition but may not change state directly. Protects: INV-08, INV-11. Participants: SVC-09; all requesting services. Required control: every state change carries a Transition Record attributable to SVC-09.

IC-02 · Gate Enforcement

A requested transition may execute only where the applicable gate has been evaluated and the gate decision is recorded as part of the same governed transition operation. Protects: INV-05, INV-08, INV-24. Participants: SVC-09 (with SVC-15 assurance). Required control: the Gate Decision Record and Transition Record are transactionally bound, share the same transition identifier, and cannot produce a completed transition independently of one another.

IC-03 · Suspension Ownership

The Lifecycle and Transition Service owns the suspension transition and record. Triggering services provide the reason and evidence. Protects: INV-08, INV-10. Participants: SVC-09; triggers from SVC-08, SVC-11, SVC-15. Required control: a Suspension Record (SVC-09) references its Suspension Recommendation or reason (originating service).

IC-04 · Reactivation through Evolution

A retired or suspended object may return to operational use only through the applicable Evolution, evaluation, justification and acceptance path. Protects: INV-05, INV-16. Participants: SVC-09, SVC-14; via SVC-10, SVC-05, SVC-06, SVC-07. Required control: reactivation produces a Transition Record and re-passes the Acceptance transition; SVC-14 supplies the Restoration Package.

13. Identity, Version and Lineage Constraints

IC-05 · Identity Immutability

No service may modify or reuse an assigned object identifier. Protects: INV-01. Participants: SVC-01; all services. Required control: identifier assignment is write-once and append-only.

IC-06 · Version Immutability

No service may overwrite a released or governed version. Corrections create a new version or an append-only correcting record. Protects: INV-12, INV-14. Participants: SVC-10; all services. Required control: version records are immutable; corrections are versioned or appended.

IC-07 · Branch and Consolidation Identity

Branching or consolidation creates successor object identities and explicit lineage links; it does not mutate predecessor identity. Protects: INV-01, INV-13. Participants: SVC-10 (with SVC-01). Required control: a Branch or Consolidation Record with predecessor and successor links.

IC-08 · Release Separation

Creating a version does not automatically release it. Release requires the applicable acceptance and governance conditions. Protects: INV-05, INV-17; AP-04. Participants: SVC-10, SVC-07. Required control: a Release Record distinct from the Version Record, linked to an Acceptance Record.

14. Evidence, Acceptance and Use Constraints

IC-09 · Justification–Acceptance Separation

The Justification Service establishes and records warrant. The Authority and Acceptance Service records authorised reliance. Neither may silently substitute for the other. Protects: INV-05, INV-07; AP-05. Participants: SVC-06 and SVC-07 (co-responsible); SVC-15 (assurance). Required control: Justification Record and Acceptance Record are distinct and separately attributable; the boundary is verified by assurance, not enforced by either peer against the other.

IC-10 · Operationalisation Eligibility

The Operationalisation Service may prepare a provisional actionable form from a non-operational object only where it is clearly marked non-releasable. It may release a form, or make it eligible for use, only when the form is linked to an accepted object version. Protects: INV-17. Participants: SVC-12 (checks SVC-07). Required control: a Warrant Linkage Record binds any releasable or usable form to an accepted version; provisional forms are marked non-releasable.

IC-11 · Application Eligibility

The Application and Outcome Service must verify acceptance, release and governance status before material use. Protects: INV-18. Participants: SVC-13 (checks SVC-07, SVC-08, SVC-09). Required control: an eligibility check recorded in the Application Record.

IC-12 · Warrant Link Preservation

No service may detach an actionable form or application record from the object version and warrant on which it depends. Protects: INV-17, INV-19; AP-05. Participants: SVC-12 and SVC-13 (co-responsible), with SVC-03 maintaining traceability and SVC-06 the warrant. Required control: warrant links are non-nullable and versioned with the form.

15. Governance and Access Constraints

IC-13 · Authority Is Not Permission

Possession of technical permission does not confer evaluation, acceptance, release, stewardship or retirement authority. Protects: INV-09, INV-11; AP-06. Participants: SVC-16, SVC-07. Required control: permission assignments and authority assignments are separate records.

IC-14 · Least Necessary Alteration

A service may alter only the records and states assigned to its logical responsibility. Protects: INV-11. Participants: all services. Required control: each record class names its authoritative maintainer (KF-3000 §24); alteration outside it is rejected and logged.

IC-15 · Material Administrative Action

Changes to authority, permissions, stewardship, retention, release or governance state are recorded and attributable. Protects: INV-09, INV-11. Participants: SVC-16 (with SVC-08). Required control: an Access and Administrative Action Log entry per material change.

IC-16 · Automated Authority Boundary

Automated services may recommend and execute authorised operations but may not become the final accountable authority where human authority is required. Protects: INV-09; AP-08. Participants: SVC-07, SVC-08; all automated services. Required control: the accountable authority on a material decision resolves to a human role or accountable body.

16. Assurance Constraints

IC-17 · Read-Only Assurance Boundary

The Conformance and Audit Service may inspect governed records and control evidence but may not alter the records it evaluates or authorise the transitions it verifies. Protects: INV-23. Participants: SVC-15. Required control: assurance operates through read-only access to the records under examination.

IC-18 · No Sole Self-Certification

Conformance may not rely solely on assertions produced by the service or actor being assessed. Each material conformance judgement must include evidence generated independently of the assessed service’s own conformance assertion — such as record inspection, cross-service reconciliation, control testing or external review. Protects: INV-22. Participants: SVC-15; all assessed services. Required control: each conformance judgement cites at least one independently generated source of the kinds named above.

IC-19 · Exception Visibility

A failed control, waived requirement or unresolved exception remains visible until corrected, formally accepted as risk, or rendered irrelevant by retirement. Protects: INV-21, INV-24. Participants: SVC-15 (with SVC-08). Required control: an Exception Register entry persists until one of the three closure conditions is recorded.

IC-23 · Proportionate Discharge

The rigour to which a material obligation is discharged — gate exit depth, control strength, required evidence and reconstruction depth — is a function of the object’s assurance classAssurance 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). Vocabulary → (KF-2003), applied at the release / scope-of-reliance to which the class attaches. Higher assurance classes require deeper discharge; lower classes require less. The lifecycle invariantsLifecycle 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). Vocabulary → are not graded: single identity, attributable transitions, justified transitions, inspectable transitions, provenance and preserved lineage hold identically at every class. Only the depth of evidence and review scales. Protects: AP-02 (Necessary and Proportionate Architecture); the six lifecycle invariants (ungraded). Participants: SVC-08, SVC-18, and every gate-executing service. Required control: each gate and control resolves the object’s assurance class and applies the minimum obligations KF-2003 fixes for that class, never less than the ungraded-invariant floor.

17. Provenance and Record Constraints

IC-20 · Provenance Continuity

Every material hand-off between actors or services preserves origin, derivation and attribution links. Protects: INV-04, INV-19. Participants: SVC-03; all services at hand-off. Required control: provenance links are carried through, not regenerated, at each hand-off.

IC-21 · Append-Only Correction

A material governed record may be corrected, but the original record and the correction relationship remain recoverable. Protects: INV-12, INV-14. Participants: all services maintaining records; SVC-10 for versioned corrections. Required control: corrections append; they do not overwrite.

IC-22 · Time Semantics Preservation

Every governed record carries recorded time and, where relevant, effective time; where the underlying event occurred at a third distinct time, event time is also preserved. (Recorded time is when the system received the fact; effective time is when it is valid in the represented domain; event time is when the real-world event occurred.) Protects: INV-14; the Common Record Properties of KF-3000 §14.8; aligns with KF-3004. Participants: all services. Required control: recorded time is mandatory on every governed record; effective and event time are recorded where they differ.

IC-24 · Event-Native Evidence

Conformance evidence is emitted by the governed act, not authored as a separate artefact. The record a governed act produces is its conformance evidence: an acceptance record evidences acceptance, a transition record is the audit event, a validation is the test result, a provenance link evidences derivation, a supersession link evidences lineage. A distinct evidence artefact is admitted only where the act’s own record cannot carry the required proof. This constraint bounds the cost of assurance and prevents the accumulation of evidence-about-evidence. Protects: INV-22; the conformance-evidence obligation (CTRL-CNF-01, KF-3005). Participants: all services producing governed records; SVC-18 reads without re-authoring. Required control: the governed act’s own record is registered as the conformance evidence for that act; a separate artefact is produced only against a recorded justification that the act’s record is insufficient. Aligns with KF-3004 §5.2.

Part V · Architectural Decision Rules

18. Decision Record Requirement

Every material architectural decision records: the question being decided; the upstream obligations affected; alternatives considered; the invariants and constraints involved; trade-offs accepted; the accountable decision-maker; the effective date; and the review or reversal condition.

19. Decision Tests

A proposed architectural decision must pass the following tests.

• 19.1 Obligation test. Which upstream obligation does the decision support?
• 19.2 Invariant test. Could the decision cause any invariant to cease to hold within its scope?
• 19.3 Separation test. Does the decision collapse concepts that KF-3000 requires to remain distinct?
• 19.4 Accountability test. Does it obscure who is answerable?
• 19.5 Traceability test. Can the resulting actions and records be reconstructed?
• 19.6 Reversibility test. Can the decision be revised without destroying history or lineage?
• 19.7 Modality test. Does the design remain valid across the computational modalities it claims to support?
• 19.8 Failure test. Does the design represent failure, unavailability and indeterminacy explicitly rather than as silent success?
• 19.9 Sufficiency test. Does the design discharge the obligation without introducing unnecessary architectural commitment?

20. Variations, Exceptions and Non-Conformance

Three cases are distinguished, and they are not interchangeable.

20.1 Architectural Variation

A design that differs from the reference form but continues to satisfy all principles, invariants and constraints is a conforming variation. It requires an Architectural Decision Record, not an exception.

20.2 Principle Exception

A time-bounded departure from an architectural principle may be permitted where: the affected principle is identified; no Canonical Principle or system invariant is violated; the rationale and risk are recorded; the exception is approved by an identified authority; its scope and duration are bounded; compensating controls are stated; and a review or expiry condition is defined.

20.3 Non-Conformance

A design or operation that violates a Canonical Principle, a system invariant or a mandatory interaction constraint is non-conforming. It cannot be converted into conformity merely by recording an exception. A proposed exception that cannot preserve an invariant is non-conformance, not an architectural variation.

Part VI · Conformance

21. Principle Conformance

Principle conformance is demonstrated through architectural decisions, mappings and design evidence showing that the principle shaped the architecture.

22. Invariant Conformance

Invariant conformance is demonstrated through preventive controls; detective checks; representative test cases; record inspection; exception and violation reporting; and evidence that the invariant remains true over time within its scope. This is the Required evidence referenced by each invariant in Part III.

23. Interaction Conformance

Interaction conformance is demonstrated through service responsibility matrices; logical service contracts; transition and authorisation tests; audit records; prohibited-path testing; and evidence that services cannot silently bypass the required interaction constraints.

24. Required Conformance Artefacts

A conforming architecture maintains: an Architectural Principle Register; an Invariant Register; a Service Interaction Constraint Register; an Assurance Class Register (recording each release’s assigned class and overlays, per KF-2003); an Architectural Decision Record Register; an Exception Register; an Invariant Test Register; a Principle-to-Capability crosswalk; an Invariant-to-Control crosswalk; and an Interaction Constraint-to-Service crosswalk.

Part VII · Crosswalks

25. Principle-to-Upstream Crosswalk

26. Invariant-to-Service Crosswalk

27. Interaction-Constraint-to-Service Crosswalk

Each constraint names the service that principally enforces it and the services that participate. (The detailed service contracts that carry these constraints are specified in KF-3003.)

Relationship to Subsequent Documents

KF-3001 governs the documents that follow.

• KF-3002 must derive capabilities consistent with these principles and sufficient to preserve all system invariants and enforce all interaction constraints.
• KF-3003 must define service responsibilities and contracts that enforce the interaction constraints, and complete the constraint-to-contract detail behind §27.
• KF-3004 must define records capable of proving invariant and transition conformance, and fix the recorded/effective/event time semantics of IC-22.
• KF-3005 must encode gates and lifecycle controls without permitting bypass, including the transactional binding of gate decision and transition (IC-02).
• KF-3008 must define authority and accountability, kept distinct from the technical permission assigned by SVC-16.
• KF-3007 must define tests and evidence for principle, invariant and interaction conformance.
• KF-3009 must preserve end-to-end traceability across all mappings.

KF-4000 may choose technologies and physical designs freely within these boundaries.

Closing Statement

Architectural freedom exists within constitutional constraint. The Knowledge Foundry Reference Architecture does not require every implementation to look the same. It requires every implementation to preserve the same essential distinctions, responsibilities, histories and lines of accountability.

KF-3001 defines those non-negotiable conditions, and fixes the grammar — principle, invariant, constraint; applied by decision, shown by conformance — in which the remainder of the architecture series is written.