KF-3000 · Knowledge Foundry Reference Architecture

The logical architecture of a governed knowledge system

Reference Architecture · Draft · v0.3 · 41 min read

Service-catalogue alignment (v0.3). The service catalogue (§12) and every service reference in this document have been renumbered to the definitive nineteen-service catalogue fixed by KF-3003. The earlier provisional sixteen-service numbering — in which, for example, SVC-05 was Evaluation and SVC-15 was Conformance — has been superseded. KF-3003 is authoritative for the service catalogue; KF-3004 is authoritative for record ownership. KF-3000’s capability enumeration (§6–§10) remains the provisional umbrella model and is refined definitively by KF-3002; a note at §12 and §23 identifies the three services (Release, Operating Condition and Exception, Temporal Continuity) whose capability grounding is established there rather than in this document’s provisional capability list.

Principle (KF-1000)
        ↓
Lifecycle (KF-2001)
        ↓
Engineering Practices (KF-2002)
        ↓
▸ Reference Architecture (KF-3000)
        ↓
Implementation (KF-4000)

Purpose

This document defines the Knowledge Foundry Reference Architecture: the technology-neutral arrangement of capabilities, services, records and control relationships required to realise the Canon, lifecycle and engineering practices of a governed knowledge systemGoverned knowledge system — a socio-technical system that holds operational knowledge objects and governs their transition from one justified state to another across modalities (KF-1001). Vocabulary →.

KF-3000 does not prescribe a product, platform, vendor, storage model or deployment topology. It defines the logical responsibilities that any conforming architecture must discharge.

The Reference Architecture answers:

What must a governed knowledge system be architecturally capable of doing?

KF-4000 answers:

How are those capabilities instantiated in a particular implementation?

Architectural Derivation

Every architectural element must be traceable to an upstream obligation.

Canonical Principle
        ↓
Lifecycle stage, gate or invariant
        ↓
Engineering practice
        ↓
Mandatory artefact or governance checkpoint
        ↓
Architectural capability
        ↓
Architectural service

An architectural component is admitted only when it can be justified by this chain. The Reference Architecture therefore does not begin with technologies. It begins with the obligations the system must preserve.

Architectural Admission Test

A proposed architectural capability or service belongs in KF-3000 only if all of the following are true:

1. It discharges one or more obligations defined in KF-2001 or KF-2002.
2. Its responsibility can be stated without naming a specific technology or product.
3. Its inputs, outputs and governed records can be identified.
4. Its relationship to accountability and authority is explicit.
5. Its conformance can be inspected or tested.
6. Removing it would leave at least one lifecycle gate, invariant, practice obligation or Governance PrimitiveGovernance Primitive — one of the six operations by which warrant is conferred: evidence, authority, provenance, validation, versioning, reversibility (KF-1104). Vocabulary → unsupported.

If a proposed element fails these tests, it belongs either in KF-4000 or outside the Knowledge Foundry architecture.

Part I · Architectural Foundations

1. Scope of the Reference Architecture

The Reference Architecture governs the operational life of Operational Knowledge ObjectsOperational 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 the engineering artefacts attached to them.

Its scope includes:

• object identity and representation;
• evidence and justification;
• acceptance and authority;
• operationalisation and application;
• provenance and traceability;
• governance and stewardship;
• versioning, branching and lineage;
• change-impact analysis;
• outcome capture;
• retirement and historical preservation;
• identity and access governance;
• confidentiality and disclosure constraints;
• integrity protection;
• role- and authority-based permissions;
• retention and lawful disposition requirements;
• conformance and audit.

Its scope does not include:

• specific software products;
• physical infrastructure;
• deployment geography;
• organisational workflow design;
• user-interface design;
• model or database selection;
• implementation-specific security technologies and controls;
• performance thresholds.

Those concerns are defined in KF-4000 or in implementation-specific profiles. The Reference Architecture states the logical obligation to control access, disclosure and integrity; it does not name the encryption, identity-management or network technologies that realise it.

2. Architectural Unit

The primary architectural unit is the Operational Knowledge Object.

The architecture must treat the following as distinct but related concerns:

Object Identity
        ≠
Object Version
        ≠
Object Representation
        ≠
Object State
        ≠
Object Lineage
        ≠
Actionable Form
        ≠
Engineering Artefact

A conforming architecture must preserve these distinctions even when an implementation stores them together.

The three that are most often confused are fixed here precisely. An object is the enduring governed identity. A version is an immutable state of that object’s represented content and attached warrant at a point in its history. A release is a version authorised for a defined scope of operational reliance. A new version does not automatically become a release, and a release does not create a new object identity.

Branching and consolidation create successor objects with new identities and explicit lineage links. They do not divide, merge or reuse the immutable identities of existing objects.

3. Architectural Invariants

The following properties must hold across the architecture:

1. Stable identity — each object has one immutable identity.
2. Persistent provenance — origin and subsequent lineage remain attached throughout the object’s life.
3. Inspectable state — the current lifecycle state and the basis for entering it are recoverable.
4. Attributable transition — every state transition is assigned to an identifiable actor or authority.
5. Justified transition — every transition carries its recorded warrant.
6. Version preservation — prior versions are retained and recoverable.
7. Separation of concerns — identity, state, version, lineage, acceptance and representation remain logically distinct.
8. Human accountability — computational execution never removes identifiable human accountability.
9. Traceable use — every material application can be traced to the object version, actionable form and acceptance-state used.
10. Historical continuity — retirement preserves the object’s record and lineage.
11. Modality independence — the obligations hold whether knowledge is represented symbolically, parametrically or through a combination of modalities.
12. Continuous conformance — governance conditions are maintained over time, not verified only once.

(KF-3001 separates these into three categories gathered here: architectural principles, system invariants, and service-interaction constraints.)

4. Architectural Perspectives

The same governed knowledge system must be inspectable through five complementary perspectives.

4.1 Object Perspective

What objects exist, how are they identified, structured, related and versioned?

4.2 Evidence Perspective

What evidence, counter-evidence, assumptions and justification warrant each object?

4.3 Lifecycle Perspective

What state is the object in, what event triggered its movement, and what gate authorised the transition?

4.4 Governance Perspective

Who owns, evaluates, accepts, reviews and retires the object?

4.5 Operational Perspective

How is the object made actionable, where is it used, and what outcomes arise from that use?

No one perspective is sufficient by itself. The architecture must preserve their relationships.

Part II · Capability Architecture

5. Capability Domains

The Reference Architecture is organised into four capability domains derived from KF-2002.

These four domains are supported by a fifth, cross-cutting domain:

The first four domains mirror the practice structure of KF-2002. The fifth gathers the three concerns that serve every domain rather than belonging to one: provenance and traceability, derived from practices A1, A2, B2, C2, C3 and D1; assurance and conformance, derived from the architectural invariants and the gates and checkpoints it exists to keep honest; and access and integrity, derived from the human-accountability and attributable-transition invariants and the Authority and Provenance Governance Primitives.

Each capability below is specified against the same compact form: Purpose, Upstream basis, Required capabilities, Principal artefacts maintained, and a Conformance condition — a single high-level, testable statement of what an independent reviewer must be able to confirm. The detailed tests are deferred to KF-3002 and KF-3007; the conformance condition makes each capability testable in principle.

6. Domain A — Identity & Representation Capabilities

A-CAP-01 · Object Registration

Purpose. Admit a candidate object and assign its durable identity.

Upstream basis. KF-2002 A1.

Required capabilities.

• assign an immutable object identifier;
• distinguish a new object from a version, branch, consolidation or duplicate;
• record the object’s origin;
• prevent identifier reuse;
• resolve an identifier to exactly one object.

Principal artefacts maintained.

• Identity Record
• Provenance Seed
• Intake Record

Conformance condition. For any object, an independent reviewer can resolve its identifier to exactly one object, retrieve its recorded origin, and confirm the identifier was never reused or reassigned.

A-CAP-02 · Structured Representation

Purpose. Represent an object in an inspectable form.

Upstream basis. KF-2002 A2.

Required capabilities.

• assign semantic type;
• represent constituent claims or elements;
• attach metadata;
• represent relationships to other objects;
• preserve the relationship between source material and structured form;
• accommodate multiple computational modalities while retaining inspectability.

Principal artefacts maintained.

• Structured Representation
• Metadata Record
• Relationship Map
• Extended Provenance Record

Conformance condition. For any object, a reviewer can retrieve its semantic type, constituent claims, metadata, relationships and provenance without reconstructing them from unstructured source material.

A-CAP-03 · Object Resolution and Discovery

Purpose. Enable authorised actors and services to locate and inspect objects and their related records.

Upstream basis. KF-2002 A1, A2 (the read side of identity and representation).

Required capabilities.

• resolve objects by identity;
• retrieve the current and historical states;
• traverse relationships and lineage;
• distinguish current, superseded, branched, consolidated, suspended and retired objects;
• expose sufficient context for downstream evaluation and governance.

Principal artefacts maintained.

• Resolution Index (a derived, rebuildable index over existing records; A-CAP-03 reads and indexes rather than originating primary records)

Conformance condition. For any identifier or relationship, a reviewer can resolve the object, retrieve its current and historical states, and traverse its lineage, distinguishing current, superseded, branched, consolidated, suspended and retired objects.

7. Domain B — Evidence & Justification Capabilities

B-CAP-01 · Evidence Registration

Purpose. Register supporting and defeating evidence as first-class governed records.

Upstream basis. KF-2002 B1 and B2.

Required capabilities.

• identify evidence independently of the claims it supports;
• classify evidence type and origin;
• attach evidence to one or more claims or objects;
• distinguish supporting, defeating and contextual evidence;
• preserve evidence provenance.

Principal artefacts maintained.

• 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 →
• Evidence-to-Claim Link
• Counter-evidence Record

Conformance condition. For any claim, a reviewer can retrieve the supporting, defeating and contextual evidence attached to it, each with its own provenance.

B-CAP-02 · Quality Evaluation

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

Upstream basis. KF-2002 B1.

Required capabilities.

• apply stated evaluation criteria;
• record pass, return or reject verdicts;
• record confidence, completeness and consistency assessments;
• retain rejected and returned evaluations;
• prevent progression where the quality gate is unmet.

Principal artefacts maintained.

• Quality Assessment
• Evaluation Verdict
• Evaluation Criteria Record

Conformance condition. For any object that advanced, a reviewer can retrieve the recorded verdict, the criteria applied and the reasons; returned and rejected objects carry the same record and did not proceed.

B-CAP-03 · Justification Construction

Purpose. Assemble and preserve the warrant for belief.

Upstream basis. KF-2002 B2.

Required capabilities.

• connect claims to supporting and counter-evidence;
• record assumptions and rationale;
• preserve traceability from claim to source;
• expose the justification to independent inspection;
• preserve an inspectable evidence, evaluation and rationale record sufficient to explain how parametrically represented knowledge or capability was admitted, bounded and relied upon.

Principal artefacts maintained.

• Justification Record
• Assumption Record
• Rationale Record
• Traceability Chain

Conformance condition. For any operational object, a reviewer can trace each material claim to its supporting and defeating evidence, recover the stated assumptions and reproduce the recorded rationale.

B-CAP-04 · Epistemic Status Management

Purpose. Represent the current epistemic standing of the object without conflating it with acceptance or lifecycle state.

Upstream basis. KF-2002 B2 (Principle VIII); the Landscape’s separation of justification from acceptance.

Required capabilities.

• distinguish unassessed, quality-assessed, warrant-established, contested, warrant-weakened and insufficiently-supported conditions;
• represent confidence and unresolved challenge;
• preserve disagreement and competing claims;
• prevent epistemic status from being overwritten by operational acceptance.

Principal artefacts maintained.

• Epistemic Status Record
• Challenge Record

Conformance condition. For any object, a reviewer can determine its current epistemic status and any unresolved challenge, and confirm that acceptance has not overwritten it.

8. Domain C — Operational Governance Capabilities

C-CAP-01 · Authority and Acceptance

Purpose. Manage the governed transition from justified object to accepted operational object.

Upstream basis. KF-2002 C1.

Required capabilities.

• identify the accepting authority;
• record acceptance, provisional acceptance or refusal;
• define the scope and conditions of reliance;
• attribute and date the decision;
• return refused objects to the appropriate stage;
• prevent operational use without valid acceptance.

Principal artefacts maintained.

• Acceptance Record
• Refusal Record
• Scope-of-Reliance Record

Conformance condition. For any operational object, a reviewer can identify the accepting authority, the decision, the date and the scope of reliance; refusals carry the authority’s recorded reasons.

C-CAP-02 · Stewardship and Ownership

Purpose. Maintain identifiable accountability throughout the operational life of the object.

Upstream basis. KF-2002 C2.

Required capabilities.

• assign and transfer stewardship;
• identify responsible roles;
• ensure no operational object is ownerless;
• preserve historical accountability;
• distinguish execution by machines from accountability held by people.

Principal artefacts maintained.

• Stewardship Assignment
• Responsibility Record
• Ownership History

Conformance condition. For any operational object, a reviewer can identify its current steward and its ownership history, and confirm that no operational object is ownerless.

C-CAP-03 · Review and Compliance

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

Upstream basis. KF-2002 C2.

Required capabilities.

• schedule and record reviews;
• detect overdue reviews;
• assess policy or governance compliance;
• suspend or flag objects whose standing gate is no longer met;
• preserve review and compliance history.

Principal artefacts maintained.

• Review Schedule
• Review Record
• Compliance Record
• Exception Record

Conformance condition. For any operational object, a reviewer can retrieve its review schedule, last review, compliance status and any exception, and the system can detect overdue reviews.

C-CAP-04 · Version and Release Management

Purpose. Preserve controlled change without loss of history.

Upstream basis. KF-2002 C2 and C3.

Required capabilities.

• create immutable versions;
• designate current, superseded and historical versions;
• preserve prior versions;
• distinguish draft, accepted and released forms;
• associate each version with its justification and acceptance-state.

Principal artefacts maintained.

• Version Record
• Release Record
• Supersession Link

Conformance condition. For any object, a reviewer can enumerate its versions, identify the current, superseded and historical versions and any releases, and confirm no prior version was overwritten.

C-CAP-05 · Lineage and Evolution

Purpose. Govern amendment, branching, consolidation, supersession and reactivation.

Upstream basis. KF-2002 C3.

Required capabilities.

• represent predecessor and successor relationships;
• preserve branch and merge lineage;
• record change triggers and rationales;
• return changed objects through evaluation, justification and acceptance;
• prevent silent mutation.

Principal artefacts maintained.

• Change Record
• Lineage Record
• Branch Record
• Consolidation Record

Conformance condition. For any change, a reviewer can recover the predecessor and successor relationships, the change trigger and rationale, and confirm the changed object returned through evaluation, justification and acceptance.

C-CAP-06 · Dependency Impact Management

Purpose. Identify and disposition objects and actionable forms affected by change.

Upstream basis. KF-2002 C3.

Required capabilities.

• identify downstream dependencies;
• determine which dependants require revalidation;
• recommend suspension, re-evaluation or evolution of affected objects;
• record their disposition;
• prevent changed knowledge from leaving dependants silently inconsistent.

Principal artefacts maintained.

• Dependency Impact Record
• Revalidation Record
• Suspension Recommendation

Conformance condition. For any change, a reviewer can identify the affected dependants and their disposition, and confirm none was left silently inconsistent.

C-CAP-07 · Event and Transition Management

Purpose. Govern movement between lifecycle states.

Upstream basis. KF-2001 (states, transitions, events, gates).

Required capabilities.

• register lifecycle events;
• evaluate transition eligibility;
• enforce exit gates;
• record forward, return, suspension, reactivation and retirement transitions;
• attribute each transition;
• preserve transition history.

Principal artefacts maintained.

• Event Record
• Transition Record
• Gate Decision Record
• Suspension Record
• Reactivation Record

Conformance condition. For any lifecycle transition, an independent reviewer can recover the triggering event, the prior and resulting states, the applicable gate, the gate decision, the accountable actor and the recorded warrant.

9. Domain D — Operational Use Capabilities

D-CAP-01 · Actionable Form Derivation

Purpose. Derive actionable forms from an accepted object — the forms usable in decisions, reasoning and automation.

Upstream basis. KF-2002 D1.

Required capabilities.

• derive decision rules, playbooks, prompts, procedures, models and other actionable forms;
• identify the object version from which each form derives;
• preserve links to justification and acceptance;
• distinguish the actionable form from the source knowledge object;
• withdraw or update actionable forms when the source object changes.

Principal artefacts maintained.

• Actionable Form
• Derivation Record
• Warrant Linkage Record

Conformance condition. For any actionable form, a reviewer can identify the object version, justification and acceptance-state from which it derives, and confirm it is withdrawn or updated when its source object changes.

D-CAP-02 · Controlled Application

Purpose. Enable governed use while preserving traceability and explainability.

Upstream basis. KF-2002 D2.

Required capabilities.

• identify the object version and actionable form used;
• verify that acceptance and governance remain valid;
• record material use — materialityMateriality — the degree to which an object, claim, decision or transition may affect consequential action, reliance, obligation, exposure, representation or preservation (KF-2003). Vocabulary → criteria and assurance classesAssurance 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 → are defined by KF-2003 · Materiality and Assurance (a domain governance profile may set additional thresholds within it);
• preserve the path from input to result;
• provide an explanation appropriate to the modality, materiality and decision context of the application, without claiming forms of interpretability the underlying representation cannot support;
• prevent use of suspended, retired or unaccepted objects.

Principal artefacts maintained.

• Application Record
• Use Context Record
• Explanation Record

Conformance condition. For every material application, a reviewer can identify the object version and actionable form used, the governing acceptance-state and the recorded path from input to result, and confirm that suspended, retired or unaccepted objects were not used.

D-CAP-03 · Outcome and Feedback Capture

Purpose. Capture what happened when knowledge was applied and return it as lifecycle evidence.

Upstream basis. KF-2002 D2.

Required capabilities.

• attach outcomes to the relevant object version and application;
• distinguish observation from judgement;
• raise review, evolution or retirement events;
• aggregate outcomes without erasing individual provenance;
• preserve adverse and contradictory outcomes.

Principal artefacts maintained.

• Outcome Record
• Feedback Record
• Trigger Record

Conformance condition. For any application, a reviewer can retrieve the captured outcomes attached to the object version, distinguish observation from judgement, and trace any review, evolution or retirement event raised from them.

D-CAP-04 · Retirement and Historical Preservation

Purpose. Conclude operational use while preserving lineage and reversibility.

Upstream basis. KF-2002 D3.

Required capabilities.

• record retirement reason, date and authority;
• remove an object from active operational use;
• preserve the full historical record;
• maintain successor and supersession links;
• assemble the restoration package that permits governed reactivation through Evolution;
• prevent destructive deletion of governed history.

Principal artefacts maintained.

• Retirement Record
• Historical Object Record
• Restoration Package

Conformance condition. For any retired object, a reviewer can identify the retirement reason, date and authority, retrieve its full historical record and lineage, and confirm that reactivation remains possible and no history was destroyed.

10. Domain E — Cross-Cutting: Provenance, Assurance & Access

Domain E is cross-cutting. It gathers the three capabilities that serve every other domain rather than belonging to one. Its assurance members do not create or alter the substantive knowledge represented by an object, nor do they authorise lifecycle transitions; they evaluate the objects, records, controls and service actions through which the architecture demonstrates conformance. Its provenance and access members maintain records of their own, but likewise never authorise a transition or alter substantive content.

E-CAP-01 · Provenance and Traceability

Purpose. Preserve origin, derivation, custody and end-to-end traceability across every stage of the object lifecycle.

Upstream basis. Architectural invariants 2, 3, 4, 9 and 10; KF-2002 A1, A2, B2, C2, C3 and D1.

Required capabilities.

• preserve source origin;
• trace representations and claims to source material;
• trace versions to predecessor versions and change events;
• trace actionable forms to object versions, justification and acceptance;
• trace applications and outcomes to the forms and versions used;
• preserve custody and attribution across transitions;
• detect broken lineage or incomplete traceability.

Principal artefacts maintained.

• Provenance Seed
• Extended Provenance Record
• Traceability Chain
• Derivation and Custody Links

Conformance condition. For any object, version, actionable form, application or outcome, a reviewer can trace it to its origin and to every predecessor state, and any broken lineage or incomplete traceability is detectable.

E-CAP-02 · Invariant Monitoring

Purpose. Continuously verify that the architectural invariants of §3 hold across all objects.

Upstream basis. Architectural invariants (§3); 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 → (KF-2001).

Required capabilities.

• evaluate each architectural invariant against live and historical objects;
• detect and record violations;
• raise conformance exceptions;
• verify continuously rather than once.

Principal artefacts maintained.

• Invariant Test Register
• Conformance Exception Record

Conformance condition. For any architectural invariant, the system can demonstrate across the object population that it holds, and any violation raises a recorded conformance exception.

E-CAP-03 · Gate and Checkpoint Assurance

Purpose. Verify that every lifecycle gate and practice governance checkpoint was enforced and satisfied.

Upstream basis. Lifecycle gates (KF-2001); practice governance checkpoints (KF-2002).

Required capabilities.

• confirm each transition passed its exit gate;
• detect gate bypass;
• verify that the checkpoint artefacts required by KF-2002 exist for each transition;
• record verification.

Principal artefacts maintained.

• Gate Conformance Record
• Checkpoint Verification Record

Conformance condition. For any transition, the system can demonstrate that its exit gate and the required KF-2002 checkpoints were enforced and satisfied, and detect any bypass.

E-CAP-04 · Artefact Completeness Verification

Purpose. Verify that every mandatory artefact required by a practice exists, is inspectable and is retrievable.

Upstream basis. KF-2002 mandatory artefacts; the artefact definition of KF-2002.

Required capabilities.

• enumerate the required artefacts for each object and lifecycle state;
• detect missing or unretrievable artefacts;
• confirm semantic completeness — that an artefact holds its required content, not merely that a record exists.

Principal artefacts maintained.

• Artefact Completeness Record

Conformance condition. For any object and lifecycle state, the system can enumerate the required artefacts and demonstrate that each exists, is retrievable and holds its required content.

E-CAP-05 · Audit and Reconstruction

Purpose. Enable independent reconstruction of an object’s full history for audit.

Upstream basis. Architectural invariants 3–5, 9–10; conformance evidence (§21).

Required capabilities.

• reconstruct the end-to-end lifecycle of any object — states, transitions, warrant, authority and use;
• produce inspectable audit trails;
• support external inspection without privileged reinterpretation.

Principal artefacts maintained.

• Audit Trail
• Reconstruction Record

Conformance condition. For any object, the system can reconstruct its end-to-end lifecycle — states, transitions, warrant, authority and use — as an inspectable audit trail, without privileged reinterpretation.

E-CAP-06 · Access and Integrity Assurance

Purpose. Ensure that governed objects, artefacts and transitions are accessed and altered only by authorised actors operating within their assigned roles.

Upstream basis. Human-accountability invariant; attributable-transition invariant; the Authority and Provenance Governance Primitives.

Required capabilities.

• distinguish authority, accountability and access permission;
• control who may view, create, modify, accept, release, apply, suspend and retire an object;
• protect governed records against unauthorised alteration;
• record access and material administrative action;
• enforce disclosure or use restrictions attached to an object;
• preserve access-control history as roles and ownership change.

Principal artefacts maintained.

• Access Policy Record
• Permission Assignment
• Disclosure Constraint Record
• Access and Administrative Action Log

Conformance condition. For any governed object, artefact or transition, a reviewer can determine which roles may view or alter it, confirm that access and material administrative actions were logged, and confirm that governed records were protected against unauthorised alteration.

A note on independence. Logical independence does not require a single implementation component. The assurance capabilities (E-CAP-02 to E-CAP-05) may be distributed across monitoring, policy-evaluation, audit and reporting components, provided assurance remains independent of the services whose conformance it evaluates.

Part III · Logical Service Architecture

11. From Capabilities to Services

An architectural service is a stable logical responsibility exposed to authorised actors or other services through defined inputs, outputs, records and controls. It may be realised by software, assigned human work, or a governed combination of both.

Capabilities state what the architecture must be able to do; services state the responsibilities through which those capabilities are made available. A service may realise several capabilities, and a capability may require several services: the relationship is many-to-many. Services are logical, not technological.

12. Core Architectural Services

This is the definitive nineteen-service catalogue, fixed here in alignment with KF-3003. It is grouped by domain: A (identity and representation); B (evidence, evaluation and justification); C (governance, lifecycle, version, release and dependency); D (operationalisation, application and retirement); and E (five cross-cutting services — provenance, access, operating condition, conformance and time). Version, acceptance and release are three separate services, and the assurance concerns previously folded into one “Conformance and Audit” service are separated into provenance (SVC-15), operating condition (SVC-17), conformance and audit (SVC-18) and temporal continuity (SVC-19).

SVC-01 · Object Registry Service

Maintains durable identity, object resolution and basic status.

SVC-02 · Representation Service

Maintains structured representations, semantic types, metadata and object relationships.

SVC-03 · Evidence Service

Registers evidence, counter-evidence and evidence relationships.

SVC-04 · Evaluation Service

Supports quality assessment, verdicts and evaluation history.

SVC-05 · Justification Service

Maintains rationale, assumptions, warrant, epistemic status and claim-to-evidence traceability, holding epistemic status distinct from acceptance.

SVC-06 · Authority and Acceptance Service

Manages acceptance decisions, authority, scope and refusal.

SVC-07 · Stewardship and Review Service

Maintains ownership, review cycles and compliance status.

SVC-08 · Lifecycle and Transition Service

Manages object state, events, gates and governed transitions — including suspension and reactivation, which are lifecycle transitions. It holds the sole authority to write lifecycle state.

SVC-09 · Version and Lineage Service

Maintains immutable versions, branches, consolidations, supersession and historical lineage, kept strictly distinct from acceptance and release.

SVC-10 · Release Service

Designates an accepted version as eligible for a defined scope and period of operational reliance, and governs withdrawal, supersession and revalidation of that eligibility. Release is a distinct governed decision, separate from version creation (SVC-09) and acceptance (SVC-06).

SVC-11 · Dependency Service

Represents dependencies and performs change-impact analysis; recommends suspension where dependants are affected.

SVC-12 · Operationalisation Service

Creates and manages actionable forms and their warrant linkages.

SVC-13 · Application and Outcome Service

Records use, explanation, results and feedback.

SVC-14 · Retirement and Preservation Service

Manages retirement, historical state and restoration packages.

SVC-15 · Provenance and Traceability Service

Maintains origin, custody, derivation and end-to-end traceability. It is the principal service of the provenance capability (E-CAP-01) and maintains the provenance and traceability artefacts produced across Domains A, B, C and D.

SVC-16 · Access and Integrity Service

Governs who may view, create, modify, accept, release, apply, suspend and retire objects and artefacts; protects governed records against unauthorised alteration; enforces disclosure constraints; and logs access and material administrative action. It mediates access and permission; it does not itself authorise lifecycle transitions or hold substantive accountability, both of which remain with human roles.

SVC-17 · Operating Condition and Exception Service

Maintains service and transaction operating condition, determines the fail-posture when a required condition is unavailable or indeterminate, and holds operational exceptions until they are closed. (Its capability basis — Operating Condition assurance — is fixed definitively in KF-3002; KF-3000’s provisional capability model folded this concern into general assurance.)

SVC-18 · Conformance and Audit Service

Verifies invariants, gates, artefact completeness and architectural conformance, and reconstructs object history for audit. It realises the assurance capabilities of Domain E and reads the records of every other service without altering them. Logical independence does not require a single component: SVC-18 may be distributed across monitoring, policy-evaluation, audit and reporting components, provided assurance remains independent of the services it evaluates.

SVC-19 · Temporal Continuity Service

Owns the common temporal model, historical sequencing, reconstruction and the preservation of recorded, effective and event time across governed records. (Its capability basis — Temporal Continuity — is fixed definitively in KF-3002; it is not enumerated in KF-3000’s provisional capability list.)

13. Service Interaction Principles

The services must interact according to the following rules:

1. No service may alter object identity after assignment.
2. No lifecycle transition may occur without a Transition Record.
3. No accepted operational object may lack a Justification Record and Acceptance Record.
4. No actionable form may exist without a traceable source object version.
5. No application may use an object whose acceptance or governance state is invalid.
6. No version change may overwrite a prior version.
7. No retirement operation may destroy lineage.
8. No automated service may become the final accountable authority.
9. All material service actions must be attributable and auditable.
10. Architectural services may automate work but may not silently bypass practice obligations.
11. The Conformance and Audit Service may read the governed records and control evidence of every service. It must not alter the records under examination, authorise the transitions it verifies, or rely solely on assertions produced by the service being assessed.
12. Access to governed records, and any change to permissions, is mediated by the Access and Integrity Service; no service grants itself access or alters its own permissions outside it.
13. Suspension and reactivation are lifecycle transitions owned by the Lifecycle and Transition Service; other services may recommend or trigger them but may not record the transition themselves.

Part IV · Architectural Records

14. Record Classes

The architecture distinguishes seven principal record classes, and a set of common properties every record must carry.

14.1 Object Records

Describe what the object is, and where it came from.

Examples: Identity Record, Intake Record, Structured Representation, Metadata Record, Relationship Map, Provenance Seed, Extended Provenance Record.

14.2 Epistemic Records

Describe why the object may be believed.

Examples: Evidence Record, Counter-evidence Record, Quality Assessment, Justification Record, Assumption Record, Rationale Record, Traceability Chain, Epistemic Status Record.

14.3 Governance Records

Describe who authorised, owns and reviews the object.

Examples: Acceptance Record, Refusal Record, Scope-of-Reliance Record, Stewardship Assignment, Review Record, Compliance Record.

14.4 Evolution Records

Describe how the object moved and changed through time.

Examples: Event Record, Transition Record, Gate Decision Record, Version Record, Change Record, Lineage Record, Dependency Impact Record, Suspension Record, Reactivation Record, Retirement Record.

14.5 Operational Records

Describe how the object was made usable and what happened when it was used.

Examples: Actionable Form, Derivation Record, Application Record, Outcome Record, Explanation Record.

14.6 Assurance Records

Describe whether the architecture is meeting its own obligations.

Examples: Invariant Test Register, Gate Conformance Record, Checkpoint Verification Record, Artefact Completeness Record, Audit Trail, Conformance Exception Record.

14.7 Access & Integrity Records

Describe who may access or alter an object, and what access occurred.

Examples: Access Policy Record, Permission Assignment, Disclosure Constraint Record, Access and Administrative Action Log.

14.8 Common Record Properties

Every governed record, of whatever class, must carry at minimum:

• a stable record identity;
• the object and version to which it relates;
• record type;
• creation time, and effective time where different;
• creator or originating service;
• accountable role where applicable;
• status;
• provenance;
• version or revision information;
• integrity status;
• retention or disposition condition;
• links to superseding or correcting records.

Where a record is corrected, the correction is appended or versioned; the prior record is not silently overwritten. The distinction between creation time and effective time is required: a policy change may be recorded on one date and take effect from another, and both must be recoverable.

15. Record Relationship Model

At minimum, the architecture must support the following logical relationships:

Operational Knowledge Object
    ├── has Identity Record
    ├── has one or more Versions
    ├── has current Lifecycle State
    ├── has Transition History
    ├── has Structured Representation
    ├── has Provenance
    ├── is supported or challenged by Evidence
    ├── has Quality Assessment
    ├── has Justification
    ├── has Epistemic Status
    ├── has Acceptance-State
    ├── has Steward
    ├── has Review History
    ├── is subject to Access and Disclosure Constraints
    ├── may derive Actionable Forms
    ├── may be used in Applications
    ├── may produce Outcomes
    ├── may depend upon or support other Objects
    ├── may branch, merge or supersede
    ├── may be Suspended
    ├── is subject to Conformance Verification
    └── may enter Historical State

The logical model fixes these relationships. It does not prescribe whether they are implemented in documents, relational tables, graphs, event streams, model context, or another substrate.

Part V · Control Architecture

16. Gate Enforcement

Each lifecycle gate must be represented as an inspectable architectural control.

Each check is enforced at execution by the Lifecycle and Transition Service (SVC-08) and verified after the fact by the Conformance and Audit Service (SVC-18): the first prevents an unearned transition, the second proves that none occurred.

17. Control Types

The architecture must support five classes of control.

17.1 Preventive Controls

Stop an invalid transition or use before it occurs.

17.2 Detective Controls

Identify missing, stale or contradictory conditions.

17.3 Corrective Controls

Return an object to an earlier stage, suspend it or trigger Evolution.

17.4 Evidentiary Controls

Produce inspectable proof that an obligation was discharged.

17.5 Historical Controls

Preserve prior states and enable reconstruction of what occurred.

18. Human Authority Boundaries

The architecture must distinguish:

• computation;
• recommendation;
• evaluation support;
• transition execution;
• accountable authorisation.

Automated systems may perform or assist the first four where permitted. They may not erase the requirement for an identifiable human authority where the Canon assigns acceptance, stewardship or accountability to a person or body.

Part VI · Conformance Architecture

19. Architectural Conformance

Conformance is assessed as coverage, not one-to-one correspondence, and to a depth proportionate to assurance class (KF-2003). A capability may be realised by several mechanisms and a mechanism may serve several capabilities; what must hold is that every obligation is covered, not that each maps to exactly one element. The nine clauses below are the structural integrity checklist; the four proportionate tests through which they are applied — Constitutional, Operational, Integrity and Reconstructability coverage — are defined authoritatively in KF-3007 · Architectural Conformance Framework. The six lifecycle invariants are demonstrated at full strength for every object regardless of class; the depth of evidence and reconstruction required of graded obligations scales with the object’s assurance class.

An implementation conforms to KF-3000 when it demonstrates that:

1. every required capability is realised by at least one identified mechanism;
2. every mandatory artefact can be produced and retrieved;
3. every governance checkpoint can be enforced or inspected;
4. every architectural invariant is maintained, at full strength, for every object;
5. every lifecycle transition is attributable and reconstructable to the depth its assurance class requires;
6. every practice in KF-2002 is supported;
7. every Governance Primitive is instantiated;
8. access and integrity controls protect governed records and are themselves inspectable;
9. no implementation choice collapses distinctions the Reference Architecture requires to remain separate.

20. Progressive Implementation Profiles

The profiles below describe progressive implementation maturity. They do not constitute full conformance with KF-3000. An implementation is conformant only when it satisfies the complete requirements of §19, or an explicitly defined domain profile approved by the Knowledge Foundry governance authority.

These implementation-maturity profiles are orthogonal to the per-object assurance classes of KF-2003: a maturity profile describes how much of the architecture an implementation has stood up, while an assurance class describes how much rigour a particular object is governed to. A Foundational implementation and a Full-Conformance one may both hold Exploratory and Consequential objects; the class sets the depth, the profile sets the reach.

The profiles are cumulative:

Foundational
    ↓ adds
Governed
    ↓ adds
Operational
    ↓ adds
Full Conformance

Foundational

Supports identity, provenance, structure, evaluation, justification and acceptance.

Governed

Adds stewardship, reviews, versioning, lineage and controlled evolution.

Operational

Adds actionable forms, governed application, outcome capture and retirement.

Full Conformance

Adds continuous assurance, dependency impact, access and integrity governance, modality independence and complete lifecycle traceability — satisfying §19 in full.

21. Conformance Evidence

A conforming implementation must be able to produce:

• a capability-to-service mapping;
• a practice-to-capability mapping;
• an artefact implementation map;
• a lifecycle gate-control map;
• an authority, access and accountability map;
• an invariant test register;
• an access and integrity control register;
• a record-retention and lawful-disposition policy;
• evidence of representative end-to-end lifecycle execution.

Wherever possible this evidence is event-native — emitted by the governed acts themselves rather than authored separately (KF-3001 IC-24; KF-3004 §5.2) — and its required depth is graded by assurance class (KF-2003). The Conformance and Audit Service (SVC-18) is the architectural means by which this evidence is produced and kept current; the model that determines what must be reconstructable, and to what depth, is KF-3007 · Architectural Conformance Framework.

Part VII · Crosswalks

22. Practice-to-Capability Crosswalk

Domain E is cross-cutting and does not map one-to-one to a practice. Its provenance capability (E-CAP-01) is derived from practices A1, A2, B2, C2, C3 and D1; its access capability (E-CAP-06) from the human-accountability and attributable-transition invariants and the Authority and Provenance Governance Primitives; and its assurance capabilities (E-CAP-02 to E-CAP-05) from the architectural invariants and the gates and checkpoints of KF-2001 and KF-2002, which they verify.

23. Capability-to-Service Crosswalk

Every capability in this document’s provisional model has a principal service. Under the definitive nineteen-service catalogue (§12), three services are grounded in the definitive capability model of KF-3002 rather than in KF-3000’s provisional enumeration: SVC-10 Release (definitive capability C-CAP-05 Release), SVC-17 Operating Condition and Exception (E-CAP-04) and SVC-19 Temporal Continuity (E-CAP-05). Within KF-3000’s provisional capabilities their responsibilities are folded respectively into version and release management (C-CAP-04), the assurance capabilities (E-CAP-02–E-CAP-05) and provenance (E-CAP-01). With provenance now seated at SVC-15 and access at SVC-16, and once the KF-3002 capability model is applied, no service is left without a capability basis.

24. Artefact-to-Service Crosswalk

This crosswalk identifies, for each mandatory artefact, the logical service that is its authoritative maintainer — the service holding primary architectural responsibility for creating and maintaining it. Other services may read an artefact; only human roles hold accountability in the normative sense reserved for Stewards and Authorities. Artefacts are grouped by the record classes of §14.

Object records

Epistemic records

Governance records

Evolution records

Operational records

Assurance records

Access & integrity records

Every mandatory artefact in this provisional set resolves to a single authoritative maintainer. Of the definitive nineteen services, seventeen maintain at least one artefact listed above; the two remaining cross-cutting services — SVC-17 Operating Condition and Exception and SVC-19 Temporal Continuity — maintain records (operating-condition status and operational exceptions; temporal, sequencing and reconstruction records) that are defined authoritatively in KF-3004 and are not enumerated in this provisional artefact list. Two allocations are set deliberately: suspension and reactivation are lifecycle transitions owned by SVC-08, while the originating service supplies the reason or recommendation; and the restoration package that supports reactivation is held by SVC-14, the maintainer of historical state.

Part VIII · Relationship to KF-4000

KF-3000 fixes the logical architecture. KF-4000 defines how that architecture is instantiated in a particular Knowledge Operating System, organisational environment or domain implementation.

An implementation may:

• combine several logical services into one component;
• distribute one service across several components;
• allocate responsibility across people and machines;
• use different storage and representation models;
• adopt different deployment and integration patterns.

It may not:

• omit a required capability;
• bypass a lifecycle gate;
• remove mandatory human accountability;
• destroy provenance, versions or lineage;
• collapse justification into acceptance;
• detach actionable forms from their warrant;
• weaken access, disclosure or integrity controls below the logical obligation;
• substitute technological sophistication for architectural conformance.

Subordinate Documents

KF-3000 is the umbrella architecture: it establishes the whole logical model and is not the place for further detail. Subordinate documents deepen specific parts without revising this one:

• KF-3001 · Architectural Principles and Invariants — separating the architectural principles, system invariants and service-interaction constraints presently gathered in §3 and §13.
• KF-3002 · Capability Model
• KF-3003 · Logical Service Catalogue
• KF-3004 · Information and Record Model
• KF-3005 · Lifecycle and Control Architecture
• KF-3006 · Architectural Integration Model — how the architectural elements collaborate to produce, govern, evolve and retire an Operational Knowledge Object; the integrated systems view that precedes conformance.
• KF-3007 · Architectural Conformance Framework — the four proportionate tests (Constitutional, Operational, Integrity, Reconstructability) through which §19 is applied, graded by assurance class.
• KF-3008 · Architectural Authority Framework
• KF-3009 · Architectural Crosswalks and Traceability

Two cross-programme documents are load-bearing for this architecture and are cited throughout: KF-2003 · Materiality and Assurance (the assurance-class scale and the depth to which graded obligations are discharged) and KF-0002 · Controlled Vocabulary and Architectural Distinctions (the authoritative terms and the user-facing projection of the architecture’s states).

Closing Statement

The Knowledge Foundry Reference Architecture is not a diagram of software components. It is the logical arrangement of responsibilities required to preserve justified knowledge as it moves through identity, evaluation, acceptance, use, change and retirement.

Its purpose is to ensure that every implementation remains answerable to the same constitutional and engineering obligations, regardless of the technologies through which those obligations are realised.