KF-3006 · Architectural Integration Model

How the architectural elements collaborate to produce, govern, evolve and retire an Operational Knowledge Object

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

Principle (KF-1000) → Lifecycle (KF-2001) → Practices (KF-2002)
        → Reference Architecture (KF-3000)
              → Domains (KF-3001 principles · KF-3002 capabilities · KF-3003 services · KF-3004 records · KF-3005 control)
              → ▸ Architectural Integration Model (KF-3006)
              → Architectural Conformance Framework (KF-3007)
        → Implementation (KF-4000)

The Knowledge Foundry Reference Architecture is intentionally modular. Each document defines one architectural concern in isolation, so that responsibilities stay clear and the architecture can evolve without unnecessary coupling. Integration therefore cannot be inferred from any single document: it is itself an architectural concern, and must be described as one. KF-3006 provides that description.

Purpose

The documents before this one describe the architecture part by part: what must remain true (KF-3001), what it must be able to do (KF-3002), where responsibility sits (KF-3003), what information exists (KF-3004), and how governed change is permitted and executed (KF-3005). Each is complete in its domain and silent on the others.

KF-3006 describes the architecture as one working system. It answers a single question:

How do all architectural elements collaborate to produce a governed 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 →?

It is the point in the KF-3000 series where the reader should feel the machine come alive: capabilities are realised by services, services are invoked by transitions, transitions pass gates, gates orchestrate controls, controls protect obligations, obligations emit evidence, evidence accumulates as traceability, and traceability is what conformance later inspects. None of that collaboration is visible from any single domain document. This one makes it visible.

KF-3006 summarises, never redefines. Where it names a service, a gate, a control, an invariant or a record, the authoritative definition remains in its home document; this model shows only how the element participates in the whole. Its value is integrative, not additive.

Figure 1 · The Integration Spine

One flow carries the whole architecture, from the obligations the Canon imposes to the conformance that inspects the result:

Canonical Principles
        ▼
Architectural Obligations
        ▼
Capabilities
        ▼
Services
        ▼
Lifecycle Transition
        ▼
Gate
        ▼
Controls
        ▼
Decision
        ▼
Evidence
        ▼
Traceability
        ▼
Conformance

Every element in the KF-3000 series occupies one band of this spine, and every chapter of this document explains one of its arrows. A reader who holds this figure in mind can place any architectural element by asking only where on the spine it acts.

Scope and the Integration Admission Test

KF-3006 is technology-neutral and deployment-neutral. It describes collaboration between architectural elements, not the components, products or topologies that realise them (those are KF-4000). A statement belongs in KF-3006 only if:

1. it describes an interaction between two or more architectural elements defined elsewhere in the series;
2. it can be stated without naming a specific technology, product or deployment; and
3. it preserves — never relaxes — 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 → and interaction constraints of KF-2001 and KF-3001.

A statement that redefines an element belongs in that element’s home document; a statement that names a technology belongs in KF-4000.

1 · Introduction

1.1 Purpose

To demonstrate that the Knowledge Foundry architecture functions as a coherent system rather than a collection of independent components, by describing the relationships and behaviours through which its elements collaborate over the life of an Operational Knowledge Object (OKOOKO — the unit of design: a versioned representation together with its attached evidence, justification and acceptance-state (KF-1101). The system governs the object, never "knowledge itself". Vocabulary →).

1.2 Scope

In scope: the relationship types between architectural elements; the behaviour of the architecture over time; the integrated journey of one OKO; the recurring integration patterns; the architectural event catalogue; and the way evidence, traceability and assurance are produced as by-products of ordinary architectural work.

Out of scope: redefinition of any element; component design; technology selection; workflow, cadence and staffing (KF-4000); and the judgement of whether an operation conforms (KF-3007).

1.3 Relationship to Other Documents

Canon (KF-1000)
     ↓ obligations
Methodology (KF-2000 · lifecycle, practices, materiality)
     ↓ methods
Reference Architecture (KF-3000)
     ↓ domains (KF-3001–KF-3005)
Architectural Integration Model (KF-3006)   ← how the architecture operates
     ↓
Architectural Conformance Framework (KF-3007)  ← whether it conforms
     ↓
Implementation (KF-4000)

KF-3006 depends on all five domain documents and on KF-2003 (assurance). It is depended upon by KF-3007, which inspects the traceability this model shows the architecture producing.

2 · Principles of Architectural Integration

These are the philosophy of integration, not its mechanics. Each is inherited from a higher level and constrains how the elements may be wired together.

1. Integration follows the Canon. Elements may be combined only in ways consistent with 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 →. Integration is not free wiring; it is constrained composition.
2. Every interaction preserves the lifecycle invariants. No collaboration between elements may break single identity, attributable transitions, justified transitions, inspectable transitions, provenance or preserved lineage. The invariants are the floor beneath every interaction (KF-2001; KF-3001).
3. Integration is event-driven, not document-driven. Elements collaborate by raising and responding to events that trigger governed transitions, not by passing documents hand to hand. What moves through the system is a governed state change, not a file (KF-2001 event model).
4. Evidence is a by-product of behaviour. Conformance evidence is emitted by the governed act, not authored by a separate administrative step (KF-3001 IC-24; KF-3004 §5.2). Integration is designed so that doing the work is recording the work.
5. Integration preserves traceability. Every interaction leaves the relationships, events and evidence needed to reconstruct what happened, to the depth 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 → requires (KF-2003; KF-3007 Test 4).
6. Responsibilities remain loosely coupled. Each capability has one accountable service and each record family one authoritative maintainer; services collaborate through governed interactions across named boundaries, never by reaching into one another’s records (KF-3003 SP-2/SP-3; KF-3004 §7). Loose coupling is what lets an implementation substitute one service without disturbing the others.

3 · Participating Architectural Elements

The elements that take part in integration, each summarised for use here; the citation is the authority.

4 · Architectural Relationships

This chapter replaces the hundreds of arrows scattered across the domain documents with a controlled vocabulary of relationship types. Every legitimate interaction in the architecture is an instance of one of these types. (These are element-level integration relationships; the record-level relationship types — VERSION_OF, RELEASES, SUPERSEDES and the rest — remain KF-3004’s.)

4.1 The Canonical Relationship Vocabulary

Every legitimate interaction is an instance of one of the nine canonical relationships below. Each belongs to a category that fixes what kind of relationship it is — so that “Service X invokes Y” and “Service X consumes Y” are never read as the same claim.

Three further structural relationships support composite decisions and grading and are used throughout the model: references — a composite decision cites the authoritative records it relied on without copying their content (KF-3004 §7.2); attributed-to — every transition resolves to an identified actor or human authority (KF-2001 invariant 2); and graded-by — the depth to which a graded obligation is discharged is set by the object’s assurance class (KF-2003; KF-3001 IC-23).

4.2 The Core Relationship Chain

Read end to end, twelve relationship types compose into one chain — the spine of the architecture:

Canonical Principle
   │ obligates
Capability ── realises ──▶ Service
                             │ invoked by
Lifecycle Transition ── invokes ──▶ Service(s)
   │ passes
Gate ── evaluates ──▶ Control(s)
                        │ protects
              Architectural Obligation / Invariant
                        │ generates
              Conformance Evidence ── accumulates as ──▶ Traceability
                                                             │ inspected by
                                                        Conformance (KF-3007)

Every arrow is one of the controlled types in §4.1. The architecture is integrated precisely because these relationships form a closed chain from principle to conformance, with no orphan element and no unnamed arrow.

4.3 Cardinality and constraint, by relationship

For the four relationships most often misread as one-to-one:

• realises (Capability→Service): one accountable service per capability; a service may be accountable for several capabilities; supporting services are many-to-many. Accountability is single; realisation is shared.
• evaluates (Gate→Control): many-to-many. One gate evaluates several controls; one control is reused across several gates.
• protects (Control→Obligation): many-to-many. One control may protect several obligations; one obligation may be protected by several controls.
• produces (Service→Record): one authoritative maintainer per record family; other services hold adjacent or derived views only (KF-3004 §7.1).

5 · Behavioural Architecture

Sections 3–4 are structural — what exists and how it relates. This section is behavioural — how the architecture acts over time.

5.1 The Event Model

The architecture does not move because a document is passed along; it moves because an event is raised. An event is what happened; the transition it triggers is the governed move it causes (KF-2001). Events divide into two kinds, and keeping them distinct is what locates automation safely:

• Trigger events (engineering events) — occurrences that oblige the system to consider a transition: new evidence, a scheduled review, a policy change, a challenge, an AI recommendation, an application outcome, an authority decision. A trigger event may be raised by a human or an agent.
• Emitted events (architectural events) — notifications the architecture publishes when a transition completes: Object Created, Acceptance Granted, Version Created, Superseded, Retired, and the rest of the catalogue in §8.

Trigger events cause transitions; transitions emit events. An emitted event may in turn be a trigger event for another service (a Version Created event triggers dependency re-checking). No event bypasses a gate. An AI recommendation is a trigger event, never an acceptance.

5.2 The Transition Model

Every governed move follows one shape, whatever the stage:

State A
   ↓  trigger event
Transition requested
   ↓  invokes services
Gate
   ↓  orchestrates
Control evaluation
   ↓  composes results
Decision   (Pass · Fail · Return · Pending · Indeterminate · Pass-with-Restriction)
   ↓  on Pass
Evidence emitted  +  Events published
   ↓
State B

This is the KF-3005 standard transition pattern seen from the integration level. The decisive property: the evidence and events at the bottom are emitted by the act, not authored afterward (§9). An Indeterminate decision is never silently treated as Pass.

5.3 The Authority Model (integrated view)

Transitions are not all equal. Some are engineering work an agent may perform under supervision; others are acts of authority that must resolve to an identifiable human. The architecture draws the line by transition, not by service:

Automation may propose any of these as a trigger event; it may not hold the authority for the acceptance, release, stewardship or retirement classes (KF-1103; KF-3000 §18; KF-3001 IC-16). The detailed authority, delegation and accountability model is KF-3008; this section shows only how authority gates the transition flow.

5.4 The Responsibility Model (integrated view)

Authority is exercised through a chain that runs from a person to a lifecycle action:

Actor
   ↓ holds
Role
   ↓ carries
Authority   (and, technically, Permission — assigned by SVC-16)
   ↓ enables
Permitted Services
   ↓ perform
Lifecycle Actions (transitions)

The chain is load-bearing in both directions: forward, it says who may act; backward, it makes every action attributable to a role, an authority and a person (invariant 2). Institutional authority (the right, held at SVC-06) and technical permission (the ability, assigned by SVC-16) are distinct and must not be conflated (KF-3001 IC-13: authority is not permission).

6 · The Integrated Object Journey

Worked example. KF-5001 instantiates this journey on a concrete Knowledge Brief, with the actual evidence, authority and records at each step.

This is the heart of the document: one OKO walked through the whole architecture. For each step it shows current state, the services invoked, the records produced, the controls evaluated, the evidence emitted, the traceability updated, and the resulting state. The journey below is generic; it is the exact path the first vertical slice — a MacroLab Singapore Business Impact Assessment, provisionally A3 Consequential — is intended to instantiate and test.

This chapter is the canonical walkthrough of the architecture. Every subsequent implementation, demonstration and conformance assessment should be understandable as an instantiation of this journey. A deployment is not a different architecture; it is this journey run on particular technology. A conformance assessment is not a separate procedure; it is this journey read backwards through its evidence.

Notation per step: State → Services → Records → Controls → Evidence → Traceability → Next state.

Capture. Candidate → SVC-01 Object Registry, SVC-15 Provenance → Identity Record, Intake Record, Provenance Seed → CTRL-ID-01 identity resolution, CTRL-ID-02 duplicate detection → evidence: the Identity and Intake records themselves → traceability: origin attached at birth → Candidate.

Structure. Candidate → SVC-02 Representation → Structured Representation, Metadata, Relationship Map → CTRL-STA-01 state validity → evidence: the structured representation → traceability: representation linked to identity → Structured.

Evaluate. Structured → SVC-04 Evaluation, SVC-03 Evidence → Evidence RecordsEvidence 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 →, Quality Assessment, Evaluation Verdict → CTRL-EVD-01 evidence presence, CTRL-EVA-01 evaluation completion → evidence: the verdict is the test result → traceability: claims linked to supporting and defeating evidence → Evaluated.

Justify. Evaluated → SVC-05 Justification → Justification Record, Assumption Record, Rationale Record, Epistemic Status → CTRL-JUS-01 justification completeness, CTRL-EVD-03 counter-evidence visibility → evidence: the justification record → traceability: end-to-end claim-to-source chain assembled → Justified.

Accept (transition, authority). Justified → SVC-06 Authority and Acceptance → Acceptance Record, Scope-of-Reliance Record → GATE-ACC-01 orchestrating CTRL-AUT-01 authority mandate, CTRL-ACC-01 acceptance validity; assurance class A3 confirmed by the governance authority here → evidence: the acceptance record is the evidence of acceptance → traceability: reliance scope + authority + date bound to the version → Accepted.

Operationalise / Release. Accepted → SVC-12 Operationalisation, SVC-10 Release → Actionable Form, Warrant Linkage, Release Record → GATE-REL-01 (state, acceptance, authority, dependency, provenance controls); depth per A3 → evidence: the release record → traceability: actionable form linked to its warrant → Operational.

Govern. Operational → SVC-07 Stewardship and Review → Stewardship Assignment, Review Schedule, Review Record → CTRL-STW-01 stewardship validity, CTRL-REV-01 review currency → evidence: review records emitted on schedule → traceability: continuing standing recorded over time → Governed.

Apply. Governed → SVC-13 Application and Outcome → Application Record, Explanation Record, Outcome Record, Feedback → GATE-APP-01 eligibility, CTRL-EXP-01 explainability, CTRL-OUT-01 outcome capture → evidence: application and outcome records → traceability: each material use tied to the version and form used → in use → outcomes.

Evolve. Outcome/new-evidence trigger → SVC-09 Version and Lineage (re-enters at Evaluate/Justify, re-accepts) → Version Record, Change Record, Lineage Record → GATE-EVO-01 (re-evaluation, re-justification, dependency disposition, renewed acceptance) → evidence: the version and change records → traceability: new version linked to predecessor; warrant re-earned, not inherited → Next Version.

Retire / Supersede. Trigger → SVC-14 Retirement and Preservation (+ SVC-09 supersession) → Retirement Record, Historical Object Record, Supersession Link → GATE-RET-01 (reason, authority, dependency disposition, preservation) → evidence: the retirement record → traceability: lineage preserved, history append-only → Historical.

Two things are visible only at this integrated scale. First, every record named above was emitted by doing the step, not by a separate filing activity — the journey is the evidence trail. Second, the six invariants held at every step: one identity throughout, every transition attributed and justified and inspectable, provenance present from Capture, lineage preserved through Evolve and Retire. The A3 class raised the depth at Evaluate, Justify, Accept and Apply; it never changed the path.

7 · Integration Patterns

The journey recurs as a small set of reusable patterns. Later implementations instantiate these rather than reinventing flow. Each pattern is a named composition of §4 relationships and the §5.2 transition shape.

• Capture Pattern — admit candidate; assign identity; record origin. (SVC-01, SVC-15; GATE-REG-01.) Establishes the invariant floor before any judgement.
• Review Pattern — evaluate and justify; assemble the claim-to-source chain. (SVC-03/04/05; GATE-EVA-01, GATE-JUS-01.) Depth graded by class.
• Acceptance Pattern — an authority certifies a scope of reliance. (SVC-06; GATE-ACC-01.) The point where justification becomes authorised reliance and class is confirmed.
• Revision Pattern — controlled change producing a new version that re-earns warrant and authority. (SVC-09; GATE-EVO-01.) Never overwrites; always links.
• Supersession Pattern — a successor replaces a predecessor for a defined scope, lineage preserved. (SVC-09/10; SUPERSEDES.)
• Retirement Pattern — end active use while preserving history. (SVC-14; GATE-RET-01.)
• Monitoring Pattern — scheduled and event-driven review that keeps standing current and raises Evolve/Retire triggers. (SVC-07, SVC-11; GATE-REV-01.)

A pattern is conformant when it preserves the invariants, attributes its transitions, and emits its evidence natively — regardless of the technology that runs it.

8 · Architectural Event Catalogue

The canonical vocabulary of emitted events (§5.1). These are the notifications the architecture publishes as transitions complete; they are the machine’s observable behaviour and the seam along which services collaborate.

Each emitted event carries, at minimum: the object and version identity, the transition, the responsible actor or authority, and recorded time (KF-3004 Common Record Properties). An event is therefore already a unit of evidence (§9). The authoritative event records are maintained by SVC-08 (Lifecycle and Transition) and the originating services; this catalogue is the shared vocabulary, not a new store.

9 · Evidence Generation Model

The principle, stated once at the integration level:

Architectural behaviour generates conformance evidence as a natural consequence of work, not through a separate administrative act.

Transition ──▶ Event ──▶ Evidence Record ──▶ Traceability Update

not

Transition ──▶ (stop) ──▶ author a separate evidence artefact

The acceptance record is the evidence of acceptance; the transition record is the audit event; the evaluation verdict is the test result; the provenance link is the evidence of derivation; the supersession link is the evidence of lineage (KF-3004 §5.2). A distinct evidence artefact is created only where the act’s own records cannot carry the required proof, and then against a recorded justification that they cannot (KF-3001 IC-24).

This is what keeps assurance affordable. Without it, a governed system generates a second knowledge-management problem — the management of evidence that the knowledge was managed. With it, the cost of assurance is folded into the cost of doing the work.

10 · Traceability Model

Traceability is not a single artefact; it accumulates in three layers, each produced by ordinary architectural behaviour.

• Structural traceability — the relationships (§4): identity → version → representation; claim → evidence; form → warrant; successor → predecessor. Produced as records are created and linked.
• Behavioural traceability — the events (§8): the ordered history of what happened to the object and when. Produced as transitions emit events.
• Evidential traceability — the proof (§9): the records demonstrating that each material obligation was discharged. Produced as the acts emit their evidence.

A conformance claimConformance claim — an assertion that an object is governed, accepted, current or reliable, reconstructable to the depth its reliance requires (KF-3007). Vocabulary → (KF-3007) is reconstructed by reading the three layers together: the relationships say what is connected, the events say what happened in order, the evidence says on what basis. The depth to which each layer must be reconstructable is set by assurance class (§11): an A0 correction need not be traceable through every principle and control; an A4 acceptance must be reconstructable end to end.

11 · Assurance Integration

This chapter bridges to KF-2003 without redefining it. It shows how assurance flows through the architecture as a single graded quantity:

Materiality (of the intended reliance)
   ↓ determines
Assurance Class   (A0 … A4, + overlays)      ── KF-2003
   ↓ sets the depth of
Required Controls        (which controls, how strong)   ── KF-3005 §32
   ↓ sets the depth of
Evidence                 (how much, how independent)     ── §9; KF-3007 Test 3
   ↓ sets the depth of
Traceability             (how far back, how complete)    ── §10; KF-3007 Test 4

The class enters the architecture at one place — the scope of reliance recorded at Acceptance and Release (SVC-06/10) — and from there parameterises gate depth (KF-3005 §28), control strength (§32) and reconstruction depth (KF-3007), all under KF-3001 IC-23. The path is invariant; the depth is graded. Two objects of different classes traverse the same journey (§6), pass the same gates and satisfy the same six invariants; the higher-class object satisfies each to greater depth. Class never lowers the invariant floor.

12 · Implementation Guidance

Technology-neutral obligations an implementation (KF-4000) must honour when realising this model. When implementing Knowledge Foundry, ensure that:

• relationships remain explicit — the §4 relationship types are recoverable, not implied by convention;
• events remain attributable — every emitted event resolves to an actor or authority and a time;
• evidence remains event-native and reconstructable — the act emits its evidence; assurance reads it without re-authoring;
• invariants remain preserved under composition — no combination of services, however optimised, breaks single identity, attribution, justification, inspectability, provenance or lineage;
• coupling remains loose — services collaborate across named boundaries and never overwrite one another’s authoritative records.

Which technologies deliver these is an implementation decision. That they are delivered is not.

13 · Relationship with the Conformance Framework

KF-3006 and KF-3007 are complementary and must not be confused:

• KF-3006 defines how the architecture operates — the relationships, behaviours, events, evidence and traceability through which a governed OKO is produced.
• KF-3007 determines whether that operation conforms — applying the four proportionate tests (Constitutional, Operational, Integrity, Reconstructability) to the traceability this model shows the architecture producing.

KF-3006 makes the machine run; KF-3007 inspects the run. The traceability layers of §10 are exactly the material KF-3007 Test 4 reconstructs, and the event-native evidence of §9 is exactly what its Test 3 grades. An architecture that integrates as described here is one that can be found conformant there — the two documents are built to meet.

14 · Emergence and Architectural Completeness

14.1 Governance Is an Emergent Property

No single architectural element creates governed knowledge. Governance emerges from the coordinated behaviour of principles, lifecycle, capabilities, services, controls, evidence and traceability acting together on one object. The properties that distinguish an Operational Knowledge Object — trustworthiness, inspectability, accountability and institutional reliance — are therefore emergent properties of the integrated architecture, not characteristics of any individual component.

This is the systems-engineering claim at the centre of the programme. Trust does not live inside an object, a service or a record; it is produced by the way they behave together. It follows that trust can be lost by a failure of integration even where every component is individually sound — a correctly built service that reaches past a boundary, an evidence record detached from the act that should have emitted it, a transition that skips its gate. Integrity is a property of the composition, which is why this document exists.

14.2 Architectural Completeness

The purpose of architectural integration is not to maximise the number of architectural elements or relationships. Its purpose is to demonstrate that every normative obligation established by the Canon can be realised, governed, evidenced and reconstructed through the integrated behaviour of the architecture — and no more than that.

This closes the loop opened by the earlier concern about a “completeness proof”. Completeness is not the property that every element maps to another element; it is the property that every obligation is discharged by the whole. An architecture is complete when the spine of §Figure 1 runs unbroken from principle to conformance for every obligation the Canon imposes, at the depth each object’s assurance class requires. Elements and relationships are justified only insofar as they serve that run; any that do not are complexity for its own sake, and the Integration Admission Test exists to keep them out.

15 · Summary

The Knowledge Foundry architecture functions as an integrated system because:

• principles constrain how elements may be composed;
• the lifecycle governs progression through stages;
• services realise capabilities under single accountability;
• transitions invoke services and gates evaluate controls;
• controls protect obligations and invariants;
• events emit evidence as a by-product of work;
• evidence accumulates as three-layer traceability;
• traceability supports proportionate conformance;
• conformance preserves the trust the whole system exists to protect.

Read alone, each domain document describes one organ. Read through this model, they are one body: an event enters, a governed transition follows, an OKO advances one justified state, and the evidence that it did so is left behind without anyone stopping to write it down.

Relationship to Subsequent Documents

• KF-3007 · Architectural Conformance Framework applies the four tests to the traceability this model produces.
• KF-3008 · Architectural Authority Framework holds the detailed authority, delegation and permission model this document views integrately in §5.3–§5.4.
• KF-3009 · Architectural Crosswalks and Traceability holds the exhaustive element-to-element mappings this document summarises.
• KF-4000 · Knowledge Operating System instantiates these relationships, behaviours and patterns in a particular deployment.

Closing Statement

KF-3006 is where the Reference Architecture stops being a set of specifications and becomes a system. It adds no new element and no new obligation; it shows that the elements already defined compose into a single governed behaviour — capability through service, transition through gate, control through evidence, evidence through traceability, traceability through conformance — and that this behaviour preserves, at every step and every assurance class, the invariants that make the object trustworthy. It is the systems view that the series needed before it could be inspected, and the map the first vertical slice will follow.