KF-3007 · Architectural Conformance Framework

How the Knowledge Foundry Reference Architecture is demonstrated to conform to its own architectural commitments

Reference Architecture · Draft for Experiment · v0.2 · 23 min read

Principle (KF-1000) → Lifecycle (KF-2001) → Materiality (KF-2003)
        → Reference Architecture (KF-3000)
              → Architectural Integration Model (KF-3006)     ← how the architecture works
              → ▸ Architectural Conformance Framework (KF-3007) ← how we know it is working
        → Implementation (KF-4000)

Up to KF-3006 the programme has been designing the architecture. KF-3007 is where the architecture becomes demonstrable — where it can show, from its own operation, that it is working as intended. It answers the question that distinguishes Knowledge Foundry from a document store, a personal knowledge tool or an AI answer engine: not does the system hold knowledge, but how can an institution demonstrate — rather than merely assert — that its knowledge architecture is functioning as intended?

A conformant architecture is not one that is believed to be correct, nor one that merely claims to satisfy its design intent. It is one whose architectural commitments can be demonstrated from observable evidence. The architecture has, in effect, begun to distinguish truth from proof: the purpose of this framework is not to establish trust by declaration, but to make trust continuously demonstrable.

Purpose

The Architectural Conformance Framework defines how the Knowledge Foundry Reference Architecture is evaluated against its own architectural commitments. It establishes the principles, criteria, evidence requirements and assessment methods through which architectural conformance may be demonstrated, monitored and reconstructed over time.

The verb is deliberate. Conformance here is not checked, audited or inspected as an external act imposed on a finished system. It is demonstrated — shown to hold from evidence the architecture already produced by operating. The whole framework rests on one sentence:

Architectural conformance is demonstrated when every material architectural claim can be reconstructed from observable evidence through explicit traceability.

That sentence links, without adding a new conceptual layer, everything the programme has built: Canonical Principles become architectural obligations; obligations are discharged through the lifecycle, services and controls; discharge emits evidence; materiality sets its depth; traceability makes it reconstructable; and reconstruction is what “demonstrated” means. The rest of this document is that sentence, unfolded.

Figure 1 · The Conformance Chain

The framework assesses along one logical chain — and the chain matters, because the assessment never evaluates an obligation directly. It evaluates whether the claim that an obligation has been discharged is supported by evidence.

Architectural Obligation
        │ asserted as
        ▼
Conformance Claim
        │ supported by
        ▼
Evidence            (event-native records)
        │ evaluated through
        ▼
Assessment          (the four tests, graded by materiality)
        │ produces
        ▼
Finding

Each chapter that follows populates one link of this chain: the obligation (§5), the claim (§9), the evidence (§10), the assessment (§7), the finding (§13). The Conformance Claim is the bridge the framework turns on: obligations are architectural facts, but conformance is always a statement about a claim, supported or not by what the architecture recorded while it worked.

Scope and the Conformance Admission Test

KF-3007 is technology-neutral. It defines how conformance is demonstrated, not the tools that store or compute the evidence (KF-4000), and not the obligations themselves (those are defined in their home documents). A statement belongs in KF-3007 only if:

it concerns how architectural conformance is demonstrated, evidenced, judged or reconstructed;
it can be stated without naming a specific technology, product or deployment; and
it references obligations defined elsewhere in the programme without redefining them.

A statement that creates a new obligation belongs in the document that owns that obligation; a statement that names a technology belongs in KF-4000.

1 · Introduction

Worked example. KF-5001 §4 demonstrates these tests, and a reconstructed Conformance Claim, on a single governed object.

1.1 Purpose

To make the architecture demonstrable: to define the obligations against which an implementation is assessed, the dimensions and tests through which assessment proceeds, the evidence on which it draws, and the findings it yields — all proportionate to the reliance placed on the knowledge governed.

1.2 Scope

In scope: the philosophy and principles of conformance; the definition of architectural conformance and of an architectural obligation; the conformance dimensions; the four-test assessment model; the conformance criteria; the Conformance Claim; the evidence model; the assessment process; findings and exceptions; architectural review; and continuous conformance.

Out of scope: the definition of any obligation (its home document); organisational compliance, HR or process audit; technology, tooling and deployment (KF-4000); and the judgement calls of a particular assessment, which this framework structures but does not pre-decide.

1.3 Relationship to Other Documents

KF-1000 · Canon — the principles from which every architectural obligation ultimately derives; conformance preserves architectural intent, and intent originates here.
KF-2001 · Lifecycle — the gates, transitions and invariants whose preservation is the substance of behavioural and lifecycle conformance.
KF-2003 · Materiality and Assurance — the assurance classes that grade how deep evidence, assessment and review must go (§11).
KF-3006 · Architectural Integration Model — describes how the architecture operates; KF-3007 determines whether that operation conforms. The traceability layers of KF-3006 §10 are exactly what this framework reconstructs.
KF-3001–3005, 3008, 3009 — the domains whose obligations are assessed and whose records supply the evidence.

KF-3006 makes the machine run; KF-3007 inspects the run. The two are built to meet.

2 · Philosophy of Conformance

Seven convictions set the tone of everything that follows.

Architecture is judged by behaviour, not by documentation. A conformant architecture is one that behaves as intended on real objects, not one that merely describes itself well. Assessment reads behaviour, not intentions.
Conformance is evidence-based. A claim of conformance stands only on observable evidence. Absent evidence, an obligation is not assessable, which is a finding in itself — never a silent pass.
Conformance is proportional. The depth of assurance demanded matches the reliance placed on the object (KF-2003). Exploratory work is not held to the standard of a board decision, and a board decision is not held to less. Proportionality applies to the depth of evidence, review and assessment — not to the architectural obligations themselves. The Canon and the lifecycle invariants remain universal; only the level of demonstration varies. Low assurance never means “no provenance”; it means less depth above an unchanged invariant floor.
Conformance is reconstructable. It is not enough that the system behaved correctly; a reviewer must be able to reconstruct that it did, after the fact, from the record.
Assessment minimises administrative burden. Because evidence is event-native (KF-3001 IC-24), assessment reads the records the architecture already produced. Conformance does not commission a parallel paperwork exercise; that would be a second knowledge-management problem.
Conformance emerges from normal operation. A well-integrated architecture is continuously demonstrating conformance simply by working. Assessment formalises and inspects that stream; it does not create it.
Assessment strengthens the architecture. Findings are not merely reports on implementation quality; they are architectural feedback that informs future revisions of the Reference Architecture itself. The architecture is a learning system, not a static specification — and its conformance framework is one of the instruments through which it learns.

3 · What Is Architectural Conformance?

Architectural conformance is the observable correspondence between the intended behaviour of the Knowledge Foundry Reference Architecture and the observable behaviour of an implemented system.

The operative word is correspondence, not compliance. Compliance suggests obedience to an external rulebook; correspondence asserts that what the architecture intends and what the system does are the same, and that the sameness can be shown. An implementation is free to differ from the reference architecture in structure, technology and arrangement (KF-3000 Part VIII); it is not free to differ in behaviour where that behaviour discharges an obligation. Conformance is the demonstrable claim that, behaviourally, it does not.

4 · Conformance Principles

Every assessment conducted under this framework shall:

preserve architectural intent — assess against the obligations the architecture actually imposes, not against a reviewer’s preference;
remain technology-neutral — judge behaviour and evidence, never the choice of tools;
rely on observable evidence — ground every finding in a record that exists, not in inference or reputation;
distinguish objective finding from judgement — separate what the evidence shows from what the assessor concludes from it, and record both;
remain reconstructable — leave its own trail, so that an assessment can itself be reviewed;
respect assurance class — demand exactly the depth KF-2003 fixes for the object, no more and no less;
preserve traceability — never break, in the act of assessing, the traceability it depends on.

5 · Architectural Obligations

The Canon establishes principles. The architecture translates them into obligations. The framework assesses whether those obligations are satisfied. The obligation is therefore the unit of conformance — the thing an assessment is of.

5.1 Where obligations come from

Obligations are not invented here; they are gathered from where they already live: Canonical Principles (via the handoff of KF-1301), lifecycle gates and the six invariants (KF-2001), engineering practices (KF-2002), the architectural principles, invariants and interaction constraints (KF-3001 AP / INV / IC), the six Governance Primitives (KF-1104), and the proportionality rules of KF-2003. The authoritative enumeration and its upstream tracing are held by KF-3009 (Crosswalks); this framework defines how any obligation is specified and assessed.

5.2 Obligation specification

Each architectural obligation is specified through five fields:

Purpose — the architectural intent it protects.
Applicable elements — the capabilities, services, gates, controls or records it binds.
Evidence expected — the records whose presence demonstrates discharge (event-native wherever possible).
Assessment method — how correspondence is shown: record inspection, cross-service reconciliation, control testing, reconstruction, or independent review.
Possible exceptions — the bounded, attributable deviations that may be accepted without breaching an invariant (§14).

Illustrative obligation. OBL — Justified Transition. Purpose: no state advances without recorded warrant (Principle VIII; invariant 3). Applicable elements: every transition; SVC-08; GATE-JUS-01 and each gate. Evidence expected: the transition record and its justification reference, emitted by the act. Assessment method: reconstruct any transition and confirm a justification is recoverable. Exceptions: none — this is invariant-protecting and ungraded.

Illustrative obligation. OBL — Sufficient Acceptance Authority. Purpose: reliance is authorised by an identifiable human authority (Principle III). Applicable elements: Accept and Release transitions; SVC-06; GATE-ACC-01. Evidence expected: the acceptance record naming authority, scope and date. Assessment method: confirm the accepting authority held a valid mandate for the object’s assurance class. Exceptions: a time-limited governance exception at one class below, recorded and visible (§14).

6 · Conformance Dimensions

Conformance is not one score. Reducing it to a single pass/fail hides where an architecture is strong and where it is thin. Assessment evaluates eight dimensions, each answering a different question:

Dimension	Asks
Structural	Do the required elements and relationships exist and remain distinct?
Behavioural	Do transitions, gates and controls behave as intended on real objects?
Lifecycle	Is the staged progression, with its gates and returns, honoured?
Governance	Are authority, stewardship, acceptance and review exercised as required?
Evidence	Is the required evidence present, event-native and proportionate?
Traceability	Can the structural, behavioural and evidential trails be reconstructed?
Authority	Does every consequential act resolve to an identifiable human authority?
Information integrity	Are records protected, single-owned and append-only where required?

A dimension may be strong while another is weak; the assessment reports the profile, not an average. Each dimension is evaluated through the four tests of §7, to the depth §11 requires.

7 · Architectural Completeness and the Assessment Model

7.1 Architectural completeness precedes conformance

Architectural conformance assumes architectural completeness. Before behaviour can be assessed, the architecture itself must demonstrate that every normative obligation established by the Canon possesses an identifiable realisation path, governance mechanism and evidential outcome. Completeness therefore evaluates the integrity of the architecture; conformance evaluates the integrity of its implementation.

The two answer different questions:

Completeness — is the architecture internally coherent? Does every obligation have somewhere to be discharged, governed and evidenced?
Conformance — does reality correspond to the architecture? Does the implemented system actually discharge them?

An incomplete architecture cannot be conformant, because there would be obligations with nowhere to be shown satisfied. Completeness is established once per architectural revision and re-checked whenever a domain document changes (§15); conformance is demonstrated continuously and per object (§16).

7.2 The four tests

The dimensions of §6 are what is assessed. The four tests below are how — the coverage logic through which any dimension is judged. They replace an open-ended list of disconnected questions with four graded tests, applied in order.

Constitutional coverage — every Canonical Principle produces at least one enforceable obligation; every obligation has at least one permissible realisation path; nothing below the line contradicts the Canon. Ungraded.
Operational coverage — every capability has an identified realisation mechanism; every transition has trigger, mechanism, authority and recorded outcome; every gate evaluates explicit exit criteria. Existence ungraded; depth graded.
Integrity coverage — every material control addresses an explicit risk, obligation, policy or invariant; every material obligation generates proportionate, event-native evidence; the six invariants hold at full strength. Graded.
Reconstructability — material status and conformance claims can be reconstructed to the depth their reliance requires; a reviewer can establish what happened, why, by whom and on what evidence. Graded.

Coverage, not correspondence: an obligation is conformant when covered by one or more mechanisms, never on condition that it maps one-to-one to a dedicated element. Single-owner accountability (one accountable service per capability, one authoritative maintainer per record family) is retained and is a different thing from realisation, which may be shared.

8 · Assessment Criteria

The four tests are applied through a practical checklist — the criteria against which evidence is read. The architecture defines these criteria; the framework applies them, which is why they are assessment criteria rather than a separate conformance standard. They are the review questions the programme has used throughout, now seated inside the tests and graded by materiality rather than posed as an absolute proof:

Does every Canonical Principle produce one or more architectural obligations? (Test 1)
Does every obligation possess at least one realisation pathway? (Test 1)
Does every capability possess one or more realisation mechanisms? (Test 2)
Does every lifecycle transition have trigger, authority, criteria and recorded outcome? (Test 2)
Does every gate evaluate explicit, inspectable exit criteria? (Test 2)
Does every material control protect an explicit obligation, risk, policy or invariant? (Test 3)
Does every material obligation generate proportionate, event-native evidence? (Test 3)
Do the six lifecycle invariants hold for every object, at full strength? (Test 3)
Can every accepted object be reconstructed to the depth its class requires? (Test 4)
Can every material conformance claim be supported from evidence through traceability? (Test 4)

A criterion answered “no” is not automatically a Non-Conformance; it is a finding (§13) whose kind depends on materiality and on whether an invariant is breached.

9 · The Conformance Claim

The framework introduces one formal concept, and only one.

A Conformance Claim is an explicit assertion that a defined architectural obligation has been satisfied for a defined object, transition or scope.

Examples: “this lifecycle transition preserved provenance”; “this acceptance possessed sufficient authority”; “this object satisfied its Consequential-class evidence obligations”; “this traceability chain is complete.” A claim is specific: it names the obligation, the subject and, where graded, the assurance class it is claimed against.

The claim is the logical hinge of the whole framework. The chain below elaborates Figure 1, making the traceability step explicit:

Conformance Claim
      │ supported by
Evidence            (event-native records — §10)
      │ read through
Traceability        (structural · behavioural · evidential — KF-3006 §10)
      │ enables
Assessment          (the four tests — §7)
      │ yields
Finding             (§13)

A claim that cannot be supported from observable evidence through explicit traceability is not thereby false — but it is not demonstrated, and an undemonstrated claim carries no conformance weight, however plausible. This is the operational meaning of the framework’s central sentence: demonstration is the reconstruction of a claim from evidence through traceability, to the depth its materiality requires.

10 · The Evidence Model

10.1 What counts as evidence

Evidence is the observable record that an obligation was discharged. The framework draws on the records the architecture already maintains (KF-3004):

event records — the emitted architectural events (KF-3006 §8);
decision records — gate decisions and their composed control results;
approval / acceptance records — authority, scope of reliance and refusals;
traceability and provenance records — origin, derivation, custody;
version and lineage history — versions, changes, supersession;
lifecycle transition records — every governed move;
relationship graphs — the structural links among objects, versions and claims.

10.2 Evidence is event-native

Wherever possible, evidence is emitted by the governed act, not authored separately (KF-3001 IC-24; KF-3004 §5.2): the acceptance record is the evidence of acceptance, the transition record is the event record of the act, the evaluation verdict is the test result. A distinct evidence artefact is created only where the act’s own records cannot carry the required proof. This is what makes assessment affordable and continuous rather than periodic and burdensome.

10.3 Independence of evidence

A conformance judgement may not rest solely on the self-assertion of the service or actor being assessed (KF-3001 IC-18). Each material judgement cites at least one independently generated source — record inspection, cross-service reconciliation, control testing or external review — and the assurance function reads records without altering them (IC-17). The Conformance and Audit Service (SVC-18) is the architectural means by which evidence is gathered and kept current; it is read-only over everything it assesses.

11 · Materiality and Assurance

This framework does not redefine materiality; it consumes it. Assurance flows as one graded quantity, entering at the scope of reliance recorded at acceptance and release:

Materiality (of the intended reliance)          ── KF-2003
      ↓ determines
Assurance Class   (A0 … A4, + overlays)
      ↓ sets
Evidence Depth        (how much, how independent)
      ↓ sets
Assessment Frequency  (how often conformance is re-demonstrated)
      ↓ sets
Required Review       (who must review, and how deep)

An A0 Exploratory object demonstrates conformance shallowly and rarely; an A4 Critical object demonstrates it comprehensively, independently and often. The invariants are never graded: identity, attribution, justification, inspectability, provenance and lineage are demonstrated at full strength at every class. Only the depth above that floor scales. Assurance class therefore parameterises every dimension (§6), every test (§7) and every review cadence (§15) at once, from a single recorded value.

12 · The Assessment Process

An assessment is technology-neutral and proceeds in seven steps:

Preparation      define scope, obligations in view, and assurance classes
      ↓
Evidence         gather the event-native records for the scope
Collection
      ↓
Analysis         apply the four tests across the applicable dimensions
      ↓
Findings         record each as Observation / Recommendation / Exception / Non-Conformance
      ↓
Exceptions       record accepted deviations, waivers and compensating controls
      ↓
Recommendations  identify improvements; assign owners
      ↓
Reassessment     re-demonstrate after remediation or at the next cadence

The process is itself governed: an assessment records its own scope, evidence, findings and reasoning, so that the assessment can be reconstructed (Conformance Principle: assessment remains reconstructable).

13 · Findings

13.1 The four kinds of finding

An individual finding is one of four kinds — mirroring mature systems-engineering and quality practice without importing its terminology wholesale:

Observation — something noted as interesting or contextual, not itself a problem.
Recommendation — an improvement opportunity; conformance is not at risk, but could be strengthened.
Exception — an intentional, attributable, bounded deviation, accepted as risk with no invariant breached (§14).
Non-Conformance — an architectural obligation is not satisfied; where an invariant is breached, the Non-Conformance is architectural, not merely operational.

13.2 The overall assessment outcome

Findings roll up into one assessment outcome, deliberately not “pass / fail”:

Conformant — obligations in scope are satisfied and demonstrated.
Conformant with observations — satisfied; observations or recommendations recorded.
Partially Conformant — some obligations satisfied; specific, bounded gaps recorded with remediation.
Non-Conformant — one or more material obligations unsatisfied, or an invariant breached.
Not Assessable — evidence is insufficient to demonstrate the claim. This is a real outcome, never silently converted to Conformant, and never to Non-Conformant either: it obliges either evidence or escalation.

Consistent with KF-3005, a Not-Assessable / Indeterminate condition is never treated as Pass, and an exception never converts an invariant breach into conformance.

13.3 Confidence in Findings

Conformance and confidence in the finding are not the same thing, and the framework keeps them distinct. Two objects may both be found Conformant while warranting very different confidence: one with complete, event-native evidence, unbroken traceability and strong provenance; another with sparse evidence, partially reconstructed history and thin traceability. Both may satisfy their obligations; our confidence that they do differs.

Every material finding therefore carries a confidence qualifier reflecting the completeness, independence and directness of the evidence it rests on — for example high (complete, event-native, independently corroborated), moderate (adequate but partly reconstructed) or low (sparse, or reliant on the assessed party’s own assertion). Confidence never changes the finding, but it travels with it: a Conformant-at-low-confidence result is a signal to strengthen evidence, not a defect in the object.

Confidence interacts with assurance class. A Consequential or Critical object found conformant only at low confidence is itself worth a recommendation (§13.1), because at high reliance the demonstrability of conformance matters as much as conformance — an obligation discharged but poorly evidenced has not been fully demonstrated. Confidence is thus how the framework surfaces the gap between being conformant and being able to show it.

14 · Exceptions

Architecture is never perfect, and a framework that cannot record imperfection drives it into hiding. Exceptions make deviation visible and governed rather than silent. The framework recognises:

accepted deviations — a difference from the reference architecture that satisfies the obligation by another means (a conforming variation);
temporary waivers — a time-limited governance exception permitting operation one class below the norm, accepted as risk by a named authority;
known limitations — an acknowledged gap not yet remediated, recorded with its consequence;
compensating controls — an alternative control that discharges the obligation where the standard mechanism cannot;
future remediation — the recorded plan and owner for closing a gap.

Every exception is attributable, bounded and visible until closed, formally accepted as risk, or rendered irrelevant by retirement (KF-3001 IC-19). No exception may waive an invariant: an invariant breach is a Non-Conformance, not an exception.

15 · Architectural Review

This chapter institutionalises architectural governance and is the home of the “completeness” discipline — recast, as elsewhere, from an absolute proof into a periodic, materiality-graded review. Review occurs at defined moments:

Continuous review — the event-native checks of §16, running as the architecture operates.
Vertical-slice review — assessment of a real object taken end to end (the first being the MacroLab Singapore assessment); the primary means by which this framework and KF-2003 are themselves validated before being frozen.
Major-release review — before a release enters consequential reliance.
Periodic architecture review — at a cadence set by the highest assurance class in scope.
Reference-architecture revision — when a domain document changes, to confirm coverage still holds.
Independent review — conducted without sole reliance on the assessed parties (IC-18), for A4 and regulated overlays.

Completeness is demonstrated here not by showing that every element maps to another, but by showing that every material obligation is discharged by the integrated behaviour of the architecture, to the depth its class requires — the spine of KF-3006 Figure 1 running unbroken, tested against real objects.

16 · Continuous Conformance

The architectural invariant of continuous conformance (KF-3000 §3) means conformance is maintained over time, not verified once. Because evidence is event-native, much of it can be demonstrated continuously by detective controls that watch the record stream and raise findings automatically:

missing or incomplete provenance;
broken or unreconstructable traceability;
invalid or illegal transitions;
expired or withdrawn acceptance still being relied upon;
transitions lacking required authority;
evidence gaps against the object’s assurance class;
stale review or breached currency conditions.

Each detected condition is raised as an event and recorded as a finding, exactly as a manual assessment would record it. Continuous conformance is periodic assessment’s complement, not its replacement: the stream catches drift as it happens; the reviews (§15) judge the whole.

17 · Relationship with Implementation

An implementation is free to innovate — to choose technologies, combine or distribute services, and arrange components as it sees fit — provided the architectural obligations remain satisfied and demonstrable. KF-3007 never dictates how an obligation is met; it requires only that its being met can be shown from evidence through traceability. Two structurally dissimilar implementations may both be fully conformant. Conformance constrains behaviour and its demonstration; it does not constrain design.

18 · Summary

Architectural conformance is not the objective of the Knowledge Foundry architecture. It is the means by which the architecture preserves trust, accountability and institutional reliance throughout its evolution. The framework:

translates principles into obligations (§5);
assesses them across dimensions (§6) through four graded tests (§7) and a practical checklist (§8);
turns each into a Conformance Claim (§9) supported by event-native evidence (§10);
grades depth by materiality (§11);
runs a reconstructable process (§12) yielding four kinds of finding and five outcomes (§13);
makes imperfection visible through exceptions (§14);
institutionalises review (§15) and continuous demonstration (§16);
and leaves implementation free to innovate within satisfied obligations (§17).

All of it collapses back to one sentence: architectural conformance is demonstrated when every material architectural claim can be reconstructed from observable evidence through explicit traceability.

Relationship to Subsequent Documents

KF-3008 · Architectural Authority Framework defines the authority whose sufficiency the Authority dimension assesses.
KF-3009 · Architectural Crosswalks and Traceability holds the authoritative obligation enumeration and upstream tracing this framework assesses against.
KF-4000 · Knowledge Operating System instantiates the evidence sources and continuous checks in a particular deployment.

Closing Statement

Across the KF-3000 series a pattern has completed: KF-3000–3005 answer what exists; KF-3006 answers how it works; KF-3007 answers how we know. Structure, then behaviour, then assurance. KF-3007 is therefore not an audit checklist appended to the architecture — it is the culmination of the architectural argument, the point at which a governed knowledge system can turn to those who rely on it and demonstrate, from its own ordinary operation, that their reliance is warranted.

Status and Next Step

This document is Draft for Experiment. Its dimensions, tests, criteria, evidence model and the Conformance Claim are hypotheses the first vertical slice is designed to test: whether evidence arises event-natively at sufficient depth, whether the four tests apply cleanly to a real object, whether the findings taxonomy is workable, and which criteria matter most in practice. It advances to Validated with Exceptions after the slice, and to Approved only after the resulting revisions and a formal architecture review. Finalising it ahead of the slice would repeat the error it corrects — deepening assurance in advance of proven use.