KF-3004 · Governed Information and Record Model

The Logical Information Architecture of the Knowledge Foundry

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

Reference Architecture (KF-3000)
        ↓
Architectural Rules (KF-3001)
        ↓
Capability and Service Models (KF-3002 / KF-3003)
        ↓
▸ Governed Information and Record Model (KF-3004)
        ↓
Control, Authority and Conformance Models (KF-3005–KF-3009)
        ↓
Implementation Schemas (KF-4000)

Purpose

KF-3004 defines the logical information objects, record classes, relationships, identity rules and temporal semantics required by the Knowledge Foundry architecture. It establishes what governed information must exist; how it is identified; how information objects relate; which single logical service maintains each authoritative record; how substantive, epistemic, governance, operational and assurance information remain distinguishable; how current and historical states are reconstructed; and how correction, supersession and retention operate without silent mutation.

KF-3004 does not prescribe database technology, table structure, file format, graph implementation, indexing strategy, API payload, physical partitioning, vendor platform or user-interface representation.

It answers:

What logical information must a conforming Knowledge Foundry implementation preserve?

Every record family in this document resolves to exactly one authoritative maintaining service in the frozen KF-3003 nineteen-service catalogue. There is no dual authoritative ownership: where two services touch a concept, one holds the authoritative record and the other holds an adjacent, related or derived view (§7.1).

Information Derivation

Canonical Obligation → Lifecycle/Practice Requirement → Invariant and Capability
→ Logical Service Responsibility → Required Information Object
→ Relationship and Temporal Semantics → Implementation Schema

Every principal information object must be traceable to a lifecycle or practice obligation; a KF-3001 invariant or constraint; a KF-3002 capability; a KF-3003 service responsibility; and a conformance or historical-reconstruction need.

Part I · Information Architecture Foundations

1. Core Information Concepts

1.1 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 →. The enduring governed subject whose identity persists across versions, representations, assessments, releases and applications. The object is not identical to a document, file, row, model instance, prompt, version, actionable form or application result; it may be represented through one or more of these.

1.2 Object Version. An immutable represented state of an object. It belongs to exactly one enduring identity, captures a bounded substantive state, cannot be silently overwritten, may have several representations, may be evaluated/justified/accepted/released, and does not automatically inherit acceptance or release from another version.

1.3 Representation. An inspectable expression of the substantive content of a version — textual, symbolic, graphical, structured, computational, parametric, multimodal or hybrid. Representation identity is distinct from object and version identity.

1.4 Governed Record. An attributable, temporally situated information object preserving evidence of an event, decision, assessment, relationship, condition, assignment, action, outcome or conformance finding. It does not necessarily contain substantive knowledge.

1.5 Reference. A governed relationship to an information object maintained authoritatively elsewhere, preserving enough to resolve its target, identify the target version or effective state, detect broken resolution and preserve historical meaning.

1.6 Information Projection. A derived, cached or indexed view of authoritative information. A projection is not authoritative; it identifies its source records, preserves refresh/effective-state information, cannot silently override the authoritative record, and may be regenerated where required.

2. Information Classes

Five classes, physically co-locatable but logically distinguishable: Substantive (what the object expresses); Epistemic (why, how strongly and under what uncertainty it may be believed); Governance (who may rely on it and under what conditions); Operational (how knowledge was transformed, used and observed); Assurance and continuity (how integrity, provenance, temporal continuity and conformance are demonstrated).

3. Information Object Admission Test

Admitted where it is required to discharge an upstream obligation; has a distinct architectural meaning; has an identifiable single authoritative maintainer; has stateable identity or relationship semantics; has definable temporal behaviour; its absence would prevent control, traceability or conformance; it is not merely an undocumented attribute of another object; and it does not duplicate an existing authoritative record.

4. Information Object Specification

Each principal information object may be specified through: Definition; Architectural purpose; Information class; Authoritative maintaining service; Identity rule; Required properties; Principal relationships; Lifecycle or status; Temporal semantics; Integrity and mutation rule; Retention and disposition; Protected invariants; Conformance test.

4.1 Information Object Granularity and Record Categories

KF-3004 identifies logical information obligations. A named information object may be implemented as an independently identified governed record, an immutable sub-record, an effective-dated status assertion, a governed relationship, a controlled property, or a non-authoritative projection. A named item requires independent record identity only where it has its own authority, effective period, correction history, provenance, retention obligation, lifecycle or conformance significance. KF-4000 determines physical normalisation while preserving these semantics — a record code is not a mandatory database table.

Each named object carries one of six record categories, which sets the specification depth required:

Core records in this document are OBJ-01, VER-01, ACC-01, TRN-01, REL-01, ACT-01, APP-01, RET-01, PRO-01, CNF-05. All others are supporting records, projections, status assertions or relationship records as marked.

5. Common Record Properties

Every governed record must contain or resolve to: stable record identity; record class; related object identity; related version identity where applicable; creator or originating service; initiating actor; accountable authority where applicable; recorded time; event time where distinct; effective time or period where applicable; status; provenance; integrity status; access classification; supersession or correction relationship; retention condition; authoritative maintaining service. A governed reference suffices where resolution and historical meaning are preserved.

5.1 Material Information Activity

“Material” is defined, so implementations neither record everything nor lose accountability. An activity is material where it can affect: identity; substantive content; epistemic standing; authority; acceptance; lifecycle state; release eligibility; dependency disposition; operational application; outcome interpretation; access or integrity; historical reconstruction; or conformance. The authoritative definition of materialityMateriality — the degree to which an object, claim, decision or transition may affect consequential action, reliance, obligation, exposure, representation or preservation (KF-2003). Vocabulary →, and the assurance-class scale that grades the depth to which material obligations must be discharged, are fixed by KF-2003 · Materiality and Assurance; KF-3005 or a domain governance profile may set additional thresholds within it.

5.2 Event-Native Conformance Evidence

Conformance evidence is, wherever possible, emitted by the governed act, not authored separately from it. The record that a governed act produces is its conformance evidence: an Acceptance Record is the evidence of acceptance; a Transition Record is the audit event; an Evaluation Verdict is the test result; a provenance link is the evidence of derivation; a Supersession Link is the evidence of lineage. A distinct evidence artefact is created only where the act’s own record cannot carry the required proof. This rule prevents a second knowledge-management problem — the management of evidence that the knowledge was managed — and is enforced architecturally by KF-3001 IC-24 and realised in the transition pattern of KF-3005 §35.

6. Identity Layers

Object Identity → Version Identity → Representation Identity → Record Identity
→ Actionable Form Identity → Application Identity → Outcome Identity

Identifiers are not interchangeable, and none may be reused for a different governed entity.

7. Authoritative Maintenance

Every information object class has one authoritative maintaining service, which creates or accepts the record, applies authorised change, preserves history, rejects unauthorised mutation, exposes current and historical state, records correction and supersession, and supplies assurance evidence. Other services may reference, annotate, request change, create supporting records or maintain projections — never overwrite the authoritative record. Maintenance responsibility does not confer human decision authority.

7.1 Adjacent Information Responsibilities

There is no dual authoritative ownership. Where two services touch one concept, one holds the authoritative record and the other holds an adjacent, related or derived view. Enforced by IC-14 (Least Necessary Alteration).

Revalidation is not a separately owned record: it appears as a disposition value in DEP-03 (dependency-driven) and as a condition on REL-01 (release-side).

7.2 Composite Decision Records

A composite decision (for example a release, which relies on an accepted version, valid acceptance, applicable authority, standing governance, dependency disposition and operating condition) must reference the authoritative records on which it relied — their identity, applicable version or effective state and decision-time status — and must not reproduce their substantive content in a way that creates a competing source of truth. This rule is load-bearing for KF-3005 gate definitions.

Part II · Relationship Architecture

8. Relationship Types

• Identity — VERSION_OF, REPRESENTS_VERSION, RECORD_CONCERNS_OBJECT.
• Derivation — DERIVED_FROM, TRANSFORMED_FROM, GENERATED_USING, CONSOLIDATED_FROM.
• Evidential — SUPPORTS, CHALLENGES, CONTEXTUALISES, EVALUATES, JUSTIFIES.
• Governance — ACCEPTS, STEWARDS, AUTHORIZES_RELIANCE_ON, RELEASES, SUSPENDS, RETIRES.
• Lifecycle — TRIGGERED_BY, EVALUATED_UNDER_GATE, TRANSITIONS_FROM, TRANSITIONS_TO, RETURNS_TO.
• Dependency — DEPENDS_ON, IMPLEMENTS, USES, CONSTRAINED_BY, INVALIDATED_BY_CHANGE_TO.
• Operational — DERIVES_FORM, APPLIES_FORM, PRODUCES_OUTCOME, EXPLAINED_BY, FEEDS_BACK_TO.
• Historical — PRECEDES, SUCCEEDS, SUPERSEDES, CORRECTS, BRANCHES_FROM, CONSOLIDATES, REACTIVATES.

9. Relationship Properties

Every material relationship must identify: relationship identity; source information object; target information object; relationship type; asserting actor/service; recorded time; effective period where relevant; provenance; status; confidence or qualification where applicable; supersession or correction history. (Relationships may connect records, versions, forms or outcomes — not only Operational Knowledge Objects.)

9.1 Relationship-Type Specification

Each load-bearing relationship is specified through: relationship code; definition; permitted source class; permitted target class; direction; cardinality; symmetry; transitivity; effective-time behaviour; qualification or confidence; authoritative asserting service; correction and withdrawal rule. The most load-bearing relationships:

Remaining relationships are completed in a controlled relationship registry using the same template. SUPERSEDES is a shared relationship type: its assertion is maintained by the service responsible for the superseded entity (a superseded version by SVC-09, a superseded release by SVC-10, a superseded form by SVC-12).

10. Relationship Integrity Rules

1. Every relationship resolves to valid source and target identities.
2. A relationship must not imply authority beyond its defined semantics.
3. A broken relationship is represented explicitly.
4. Historical relationships are not deleted when superseded.
5. Derived relationships preserve their basis.
6. Symmetry and transitivity are not assumed unless the type defines them.
7. Dependency direction is explicit.
8. Relationship status and object status remain distinct.
9. Relationship correction creates a new governed state or correction record.

Part III · Temporal and Historical Architecture

11. Time Semantics

Event time, recorded time, effective time, decision time and processing time may coincide but must not be treated as identical by default.

SVC-19 (Temporal Continuity) governs the common temporal model, historical sequencing and reconstruction rules. Each authoritative maintaining service remains responsible for the effective period and temporal assertions of the records it maintains — SVC-06 for an Acceptance Record’s effective period, SVC-10 for a Release Record’s, SVC-07 for a Stewardship Assignment’s. SVC-19 owns temporal conventions, sequence integrity, reconstruction and migration history; it does not approve or maintain each substantive validity decision.

12. Effective Periods

A record governing continuing conditions must support effective-from, effective-to, open-ended validity, scheduled future effect, retrospective recording, revocation, supersession, suspension and reactivation. A later recorded fact may have an earlier effective time, so reconstruction must not rely solely on record-creation order.

13. Historical Reconstruction

The architecture must reconstruct, at a specified time: substantive representation; epistemic standing; acceptance and release status; steward and applicable authority; lifecycle state; known dependencies; actionable forms; operating and integrity condition; relevant exceptions; and historical application eligibility. Reconstruction must distinguish what the system knew then from what the system knows now about then.

14. Mutation, Correction and Supersession

Governed records are not silently overwritten. Permitted patterns: append; new immutable version; status transition; explicit correction; supersession; revocation; expiration; historical annotation. A correction must preserve the original record, correction reason, correcting actor/service, correction time, corrected content or interpretation, and the relationship between original and corrected state.

15. Deletion and Disposition

Logical deletion must not erase information required for identity continuity, accountability, provenance, historical reconstruction, legal/policy retention or conformance evidence. Disposition may include active/restricted retention, archival preservation, anonymisation, de-identification, cryptographic erasure of protected content, or deletion after retention expiry. The record of disposition remains governed where accountability requires it.

15.1 Current State and Event History

Where both a current-state record and an event history exist:

1. the event or transition record preserves the authoritative historical act;
2. the current-state record represents the effective current state;
3. both are updated or established within one governed operation;
4. disagreement between them produces an indeterminate integrity condition;
5. current state must be reconstructable from valid historical events;
6. correction does not erase the original event.

This applies to lifecycle state, release status, form status, epistemic standing, stewardship and operating condition. In each case the current-state record is an effective-dated assertion established transactionally with its event; it is not a free-standing mutable value.

Part IV · Domain A — Identity and Representation Information

Record Family A1 · Object Identity — maintained by SVC-01 · Object Registry

OBJ-01 · Object Identity Record (Core Record). The authoritative record of an object’s enduring identity. Required properties: object identifier; object class; registration status; origin reference; registration time; registration decision; identity-resolution status; applicable predecessor or source relationship; current lifecycle-state projection or reference (authoritative state is LIF-01, SVC-08). Principal relationships: HAS_VERSION; ORIGINATED_FROM; BRANCHES_FROM; CONSOLIDATES; HAS_STEWARD; HAS_LIFECYCLE_STATE. Mutation rule: object identifier immutable; classification and descriptive metadata may change through governed correction. Conformance test: every governed object resolves to exactly one enduring Object Identity Record, regardless of lifecycle state. Protects: INV-01, IC-05.

OBJ-02 · Intake Record (Supporting). Submitted material, source, intake context, initiating actor, classification request, duplicate-search result, routing decision.

OBJ-03 · Identity Resolution Decision (Supporting). Whether intake represents a new object, candidate version, branch candidate, consolidation candidate, duplicate or unresolved identity.

Record Family A2 · Representation — maintained by SVC-02 · Representation

REP-01 · Structured Representation (Supporting). Substantive content, semantic structure, constituent claims/elements, representation modality, limitations, object and version identity.

REP-02 · Semantic Type Record (Controlled Vocabulary). Semantic classification applied to an object, representation, claim or relationship.

REP-03 · Representation Limitation Record (Supporting). Known opacity, incompleteness, approximation, modality limitation, interpretation constraint, unsupported use.

REP-04 · Object Relationship Record (Relationship Record). Governed semantic relationships among objects, versions or elements.

Record Family A3 · Resolution and Discovery — maintained by SVC-01 · Object Registry (RES-02 is a projection)

RES-01 · Resolution Result (Projection). Query/identifier supplied; target resolved; ambiguity; resolution basis; current or historical context; access filtering; retrieval time.

RES-02 · Governed Context Package (Projection). A non-authoritative assembled view referencing identity, version, representation, epistemic standing, acceptance, release, lifecycle state, provenance, stewardship and restrictions.

RES-03 · Retrieval Provenance Record (Supporting). Requested information; requester; source records accessed; projection/cache use; version returned; retrieval time.

Part V · Domain B — Evidence and Justification Information

Record Family B1 · Evidence — maintained by SVC-03 · Evidence

EVD-01 · 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 → (Supporting). Evidence identifier; type; origin; creator/source; content or source reference; custody; availability; integrity status; effective period where applicable.

EVD-02 · Evidence Relationship Record (Relationship Record). Relates evidence to claim, object, version, evaluation or justification; role: supports, challenges, limits, contextualises, corroborates. The “counter” quality belongs to this relationship role, not to the evidence object — the same evidence may support one claim and challenge another.

EVD-03 · Material Counter-Evidence Assertion (Supporting). Exists only where a material challenge must be made visible in acceptance and review. It preserves INV-06 without implying that an item is intrinsically “counter-evidence.” Protects: INV-06.

EVD-04 · Evidence Availability Status (Status Assertion). Available, restricted, unavailable, inaccessible, destroyed, unresolved, provenance-incomplete.

Record Family B2 · Evaluation — maintained by SVC-04 · Evaluation

EVA-01 · Evaluation Criteria Record (Supporting). Criterion; applicability; threshold; scoring/judgement method; effective period; exception rule.

EVA-02 · Quality Assessment Record (Supporting). Object/evidence assessed; criteria applied; evaluator; inputs; findings; evaluation confidence (distinct from epistemic confidence — §7.1); limitations; assessment time. Includes an assessment-progression value: not assessed, pending, in progress, completed, reassessment required.

EVA-03 · Evaluation Verdict Record (Status Assertion). Pass, fail, return, pending, indeterminate; never inferred solely from score. Protects: INV-24.

EVA-04 · Evaluation Exception Record (Supporting). A permitted procedural deviation that does not convert an invariant violation into conformance.

Record Family B3 · Justification and Epistemic Standing — maintained by SVC-05 · Justification

JUS-01 · Justification Record (Supporting). Structured warrant referencing claims, evidence, counter-evidence assertions, evaluations, rationale, assumptions, unresolved challenges, confidence, limitations. Protects: INV-05, IC-09.

JUS-02 · Assumption Record (Supporting). Statement; source/basis; scope; confidence; materiality; review condition.

JUS-03 · Rationale Record (Supporting). The reasoning connecting evidence and assumptions to a conclusion.

JUS-04 · Challenge Record (Supporting). A resolved or unresolved challenge to the warrant.

EPS-01 · Epistemic Standing Record (Status Assertion). The current epistemic conclusion: unsupported, provisionally supported, supported, strongly supported, weakened, indeterminate. Independent of lifecycle, acceptance and release, and independent of assessment progression (held in EVA-02) and contestation (EPS-03). Protects: INV-03, INV-07.

EPS-02 · Epistemic Standing Change Record (Supporting). Prior standing; new standing; triggering evidence or assessment; responsible actor/service; recorded and effective time.

EPS-03 · Contestation Status Record (Status Assertion). Not contested, contested, materially contested, resolved. An object may be supported and contested simultaneously; these are separate dimensions.

Part VI · Domain C — Governance and Change Information

Record Family C1 · Authority and Acceptance — maintained by SVC-06 · Authority and Acceptance

AUT-01 · Authority Mandate Record (Supporting). Authority holder or accountable body; source; mandate; scope; effective period; delegation; constraints; revocation status. KF-3008 defines the full authority model; KF-3004 defines the information to represent it. (Held by SVC-06, not SVC-16: institutional authority is not technical permission.)

AUT-02 · Accountable Body Record (Supporting). Body identity; formal mandate; membership; quorum or decision rule; effective period; delegated authority; decision-record requirements.

ACC-01 · Acceptance Record (Core Record). Object version accepted; accepting authority; decision; reliance scope; conditions; duration; justification reference; epistemic standing at decision time; decision rationale. Protects: INV-05, INV-08, INV-09.

ACC-02 · Refusal Record (Supporting). The refusal decision and reasons, without changing epistemic standing.

ACC-03 · Acceptance Condition Record (Supporting). Restricted use; provisional reliance; mandatory review; limited population; geographic scope; expiry; human-oversight requirement.

Record Family C2 · Stewardship and Review — maintained by SVC-07 · Stewardship and Review

STW-01 · Stewardship Assignment (Supporting). Object; steward; mandate; start/end time; assignment authority; responsibility scope; transfer history. Protects: INV-09, INV-10.

STW-02 · Stewardship Transfer Record (Supporting). Preserves transfer without creating an ownerless period.

REV-01 · Review Schedule (Supporting). Review type; frequency; trigger; due date; responsible party; escalation rule.

REV-02 · Review Record (Supporting). Review scope; reviewer; evidence considered; findings; disposition; required actions.

CMP-01 · Compliance Assessment (Supporting). Distinguishes formal compliance from substantive review.

GOV-01 · Governance Exception Record (Supporting). Rule or principle affected; scope; authority; rationale; duration; compensating control; expiry; review status. (Distinct from operational exception EXC-01 — §7.1.)

Record Family C3 · Lifecycle and Transition — maintained by SVC-08 · Lifecycle and Transition

LIF-01 · Lifecycle State Record (Status Assertion). The authoritative current lifecycle state, established transactionally with its transition (§15.1). States are defined by KF-3005 and are not inferred from epistemic standing, release, version status or application activity. Protects: INV-03, IC-01.

EVT-01 · Lifecycle Event Record (Supporting). A material event capable of triggering review, transition, suspension, evolution or retirement.

GAT-01 · Gate Decision Record (Supporting). Transition identifier; current state; proposed state; applicable gate; criteria; evidence; result; accountable authority; operating condition; decision time.

TRN-01 · Transition Record (Core Record). Transition identifier; prior state; resulting state; execution actor/service; accountable authority; gate-decision reference; effective time; completion status. Gate Decision and Transition Records are transactionally bound under one transition identifier. Protects: INV-08, INV-14, IC-01, IC-02.

Record Family C4 · Version, Lineage and Change — maintained by SVC-09 · Version and Lineage

VER-01 · Object Version Record (Core Record). Version identifier; object identifier; predecessor version; change rationale; creation event; substantive fingerprint; candidate or governed status; correction and supersession links. Integrity rule: substantive content immutable after establishment. Protects: INV-12, IC-06.

CHG-01 · Change Record (Supporting). Proposed change; trigger; rationale; affected content; responsible actor; resulting version or object; review route. Also the record through which a REA-01 reactivation enters governed evolution.

LIN-01 · Lineage Record (Relationship Record). Predecessor; successor; branch; consolidation; correction; supersession; reactivation. Protects: INV-13.

BRN-01 · Branch Record (Supporting). Creation of a new enduring object identity derived from an existing object (successor identity assigned via SVC-01; IC-07).

CON-01 · Consolidation Record (Supporting). Creation of one successor object from multiple predecessors.

COR-01 · Correction Record (Supporting). Preserves the original record and the correction. The authoritative record of correction; SVC-19 reconstructs correction history from COR-01 plus recorded time, effective time, supersession relationships and provenance — there is no separate correction-history record. Protects: INV-14, IC-21.

SUP-01 · Supersession Record (Relationship Record). Version and lineage supersession. Supersession of a release or form is asserted by the service owning that entity (SVC-10, SVC-12) — see §9.1.

Record Family C5 · Release — maintained by SVC-10 · Release

REL-01 · Release Record (Core Record). Released object version; acceptance reference; release authority; release scope; effective period; conditions; status; withdrawal or supersession reference; revalidation condition. A composite decision record per §7.2. Protects: INV-17, IC-08.

REL-02 · Release Status Record (Status Assertion). Candidate, active, restricted, suspended, withdrawn, expired, superseded. Independent of object lifecycle state.

Record Family C6 · Dependency and Impact — maintained by SVC-11 · Dependency

DEP-01 · Dependency Record (Relationship Record). Material reliance between objects, versions, representations, actionable forms, applications or controls.

DEP-02 · Dependency Impact Record (Supporting). Triggering change; affected dependants; impact classification; analysis basis; uncertainty; required action. Protects: INV-15.

DEP-03 · Dependency Disposition Record (Supporting). No action, review, revalidation, evolution, restriction, suspension, withdrawal, retirement.

Part VII · Domain D — Operational Use Information

Record Family D1 · Actionable Forms — maintained by SVC-12 · Operationalisation

ACT-01 · Actionable Form Record (Core Record). Form identity; source object and version; form type; derivation method; warrant linkage; release status; intended context; prohibited use; effective period. Protects: INV-17, IC-10, IC-12.

ACT-02 · Derivation Record (Supporting). How the form was derived from its source knowledge.

ACT-03 · Actionable Form Release Record (Supporting). Form eligibility, independent of the underlying object release.

ACT-04 · Form Status Record (Status Assertion). Provisional, under review, eligible, restricted, suspended, withdrawn, superseded.

Record Family D2 · Application — maintained by SVC-13 · Application and Outcome

APP-01 · Application Record (Core Record). Application identity; form identity; source object version; applicable warrant/justification reference (resolved via the actionable form); purpose; context; actor or system; effective eligibility decision; inputs; output or action; time; materiality. Protects: INV-18, INV-19, IC-12.

APP-02 · Eligibility Decision Record (Supporting). Whether application was permitted at the time of use. Protects: IC-11.

APP-03 · Use Context Record (Supporting). Population; environment; jurisdiction; process; materiality; risk; constraints; human-oversight condition.

APP-04 · Application Participant Record (Supporting). Initiating human; accountable human; executing service; computational model; reviewing human; affected party where governed.

EXP-01 · Explanation Record (Supporting). Proportionate to modality, materiality, risk, decision context and governance profile. Protects: INV-20.

Record Family D3 · Outcome and Feedback — maintained by SVC-13 · Application and Outcome

OUT-01 · Outcome Record (Supporting). An observed result; observation distinguishable from interpretation.

OUT-02 · Outcome Interpretation Record (Supporting). The meaning attributed to an outcome and its basis.

OUT-03 · Materiality Assessment (Supporting). No action, monitoring, review, evidence registration, restriction, suspension, evolution, retirement.

FDB-01 · Feedback Record (Supporting). Routes material learning back into evidence, review, evaluation or evolution.

Record Family D4 · Retirement and Preservation — maintained by SVC-14 · Retirement and Preservation

RET-01 · Retirement Record (Core Record). Object retired; retirement authority; rationale; effective time; successor where applicable; preservation disposition; reactivation conditions. Protects: INV-16, IC-04.

PRE-01 · Preservation Record (Supporting). How the retired object’s identity, versions, warrant, governance history, forms, applications, outcomes and provenance remain recoverable.

REA-01 · Reactivation Request (Supporting). Initiates governed evolution through CHG-01; does not restore operational status directly.

HIS-01 · Historical Object Record (Projection). A governed historical view or package used for retrieval after retirement.

Part VIII · Domain E — Assurance and Continuity Information

Record Family E1 · Provenance and Custody — maintained by SVC-15 · Provenance and Traceability

PRO-01 · Provenance Record (Core Record). Origin, derivation, attribution and custody across material information objects (why-, where-, how-, who-provenance). Protects: INV-04, IC-20.

PRO-02 · Derivation Link (Relationship Record). Relates a derived information object to its source inputs and transformation event.

PRO-03 · Custody Record (Supporting). A custody event or custody assignment. The ordered historical custody sequence is reconstructed by SVC-19 from these events.

PRO-04 · Provenance Gap Record (Supporting). Missing, incomplete, disputed or inaccessible provenance; never represented as complete lineage.

Record Family E2 · Access and Integrity — maintained by SVC-16 · Access and Integrity

ACS-01 · Access Policy Record (Supporting). Permitted access and action by actor/role, object class, service, information classification, action, context, effective period.

ACS-02 · Permission Assignment (Supporting). Technical permission, independent of institutional authority (AUT-01). Protects: IC-13.

ACS-03 · Disclosure Constraint (Supporting). Confidentiality, sharing and use limitations.

INT-01 · Integrity Status Record (Status Assertion). Verified, altered, corrupted, incomplete, unverifiable, under investigation.

ADM-01 · Administrative Action Record (Supporting). Material privileged actions affecting permissions, policies, configuration, retention, integrity or access. Protects: INV-11, IC-15.

Record Family E3 · Operating Condition and Exception — maintained by SVC-17 · Operating Condition and Exception

OPR-01 · Operating Condition Record (Status Assertion). Operational, degraded, unavailable, pending, failed, indeterminate. Protects: INV-24.

OPR-02 · Degradation Record (Supporting). Affected capability/service; scope; start time; consequence; fail-open or fail-closed rule; compensating control; recovery status.

OPR-03 · Failure Disposition Record (Supporting). The governed response to a failure or indeterminate condition.

EXC-01 · Operational Exception Record (Supporting). Distinguished from governance exceptions (GOV-01) and assurance exception references. Protects: IC-19.

REC-01 · Recovery and Reconciliation Record (Supporting). Recovered operations; deferred records; reconciliation checks; residual discrepancies; closure authority.

Record Family E4 · Temporal Continuity — maintained by SVC-19 · Temporal Continuity

TMP-01 · Temporal Metadata Record (Supporting). Recorded, event, effective, decision and processing time where applicable. Protects: IC-22.

TMP-02 · Effective Period Record (Supporting). The common effective-period model and scheduled-effect conventions. Substantive validity is asserted by each maintaining service (§11); TMP-02 provides the shared representation, not the decision.

TMP-03 · Historical Reconstruction Result (Projection). A generated, non-authoritative view of the object and its context at a specified point or interval.

TMP-04 · Retention Condition Record (Supporting). Retention, archive, restriction and disposition conditions.

TMP-05 · Format or Custody Migration Record (Supporting). Preserves authenticity through an actual format or custody migration event.

Record Family E5 · Conformance and Audit — maintained by SVC-18 · Conformance and Audit

CNF-01 · Conformance Assessment (Supporting). Scope, criteria, evidence, assessor, conclusion. Protects: INV-21, INV-22.

CNF-02 · Invariant Test Result (Supporting). Holds, fails, indeterminate, outside scope.

CNF-03 · Interaction Constraint Test Result (Supporting). Whether a prohibited or mandatory service path was respected.

CNF-04 · Assurance Finding (Supporting). No action, monitoring, correction, control improvement, suspension, formal non-conformance.

CNF-05 · Non-Conformance Record (Core Record). Violated obligation; affected scope; severity; evidence; corrective action; accountable authority; status.

CNF-06 · Corrective Action Record (Supporting). Required remediation and verification. SVC-18 must not alter the operational records assessed. Protects: INV-23, IC-17.

Part IX · Information Integrity Rules

16. Object and version integrity. One enduring identity per object; every version belongs to one object; version content immutable after establishment; new versions do not create new object identities; branching and consolidation create successor identities; release and acceptance do not create versions; retirement does not erase identity.

17. Record integrity. Every material event and decision (per §5.1) has a governed record; records are attributable; material records preserve applicable authority; corrections do not erase originals; record status is explicit; missing information is not represented as affirmative evidence; projections do not supersede authoritative records; records under assurance review cannot be silently altered; a composite decision references rather than copies the records it relied on (§7.2).

18. State separation. These remain distinct, none inferred solely from another unless KF-3005 defines a formal derivation rule: object lifecycle state; version status; representation status; epistemic standing; assessment progression; contestation; acceptance status; release status; actionable-form status; service operating condition; conformance status.

19. Authority and permission separation. A permission record (ACS-02, SVC-16) establishes that an actor/service may technically perform an action; an authority record (AUT-01, SVC-06) establishes that a human authority or accountable body may make a governed decision. Both may be required; neither substitutes for the other.

20. Provenance integrity. Every material information object preserves or resolves to origin, creator/source, derivation, custody, related object and version, material transformation and known gaps. Broken provenance is explicit.

21. Temporal integrity. Recorded time is never substituted for effective time; retrospective recording is identified; future-effective decisions are not treated as currently effective; expired decisions do not remain silently active; reconstruction preserves knowledge available at the target time; later correction is distinguishable from the earlier state; sequence ambiguity is represented as indeterminate where unresolved.

Part X · Information Interaction Contracts

22. Record creation. A service may create an authoritative record only where KF-3003 assigns it maintenance responsibility. 23. Record reference. A referencing service preserves target identity, target version or effective state, relationship type, reference time and resolution status. 24. Change request. A service may request but not directly apply change to another service’s record. 25. Event publication. Material creation, change, suspension, withdrawal, correction and retirement events are made available to affected services without transferring authority or mutating receiving records. 26. Projection and caching. A projection identifies authoritative source, source version or effective state, creation time, freshness and invalidation conditions and access restrictions; a stale projection is never presented as current authoritative state.

Part XI · Information Conformance

27. Information conformance. Every required object class is represented; every authoritative record has one maintaining service; identity semantics are preserved; required relationships are resolvable; current and historical states are distinguishable; correction and supersession preserve prior states; temporal semantics are explicit; protected information is access-controlled; missing or indeterminate information is visible; and information supports all required invariant and interaction-constraint tests.

28. Information conformance evidence. Logical information model; authoritative-maintainer matrix; identity tests; relationship-integrity tests; temporal-reconstruction tests; correction and supersession tests; version-immutability tests; state-separation tests; access and authority checks; provenance-path reconstruction; cross-service reconciliation; retention and disposition evidence.

29. Representative reconstruction test.

Outcome → Application → Actionable Form → Released Object Version →
Acceptance Decision → Epistemic Standing → Justification →
Evidence and Counter-Evidence → Representation → Object Identity and Origin

The reconstruction must also reveal the responsible human authority, applicable steward, lifecycle transitions, dependencies, access and integrity condition, operating condition, known provenance gaps, relevant exceptions and conformance findings.

Part XII · Crosswalks

30. Information-Object-to-Service Crosswalk (frozen KF-3003 catalogue; one maintainer per family)

31. Capability-to-Information Crosswalk

32. Invariant-to-Information Crosswalk

33. Interaction-Constraint-to-Information Crosswalk

34. Lifecycle-to-Information Crosswalk (KF-2001 stages)

Part XIII · Relationship to Subsequent Documents

KF-3005 defines lifecycle states, gate conditions, transition rules and permissible/prohibited state changes; KF-3004 defines the records through which those controls are represented and evidenced, and the current-state/event-history rule (§15.1) they must honour. KF-3008 defines the authority model behind AUT-01/02 and the delegation, stewardship, access and computational-participation assignments; KF-3004 defines the logical records that represent them. KF-3007 defines the tests and evidence for information, service and system conformance. KF-3009 preserves traceability from Canonical PrincipleCanonical Principle — an enduring obligation true of any governed knowledge system, admitted only if it survives the two-question test (KF-1000 Part III). Vocabulary → through practice, invariant, capability, service, information object, control and implementation.

KF-4000 may implement this logical architecture through relational, graph, document, event-stream, object-store, ledger, file or human-maintained structures, and may denormalise, replicate, index or distribute — provided it does not create conflicting authoritative records, collapse required semantic distinctions, overwrite immutable history, remove required provenance, substitute a projection for authoritative state, make historical reconstruction impossible, treat missing or indeterminate information as satisfied, or prevent independent conformance inspection.

Closing Statement

The Governed Information and Record Model defines the memory of the Knowledge Foundry architecture. It ensures that substantive knowledge, warrant, authority, operational use and assurance remain distinguishable yet connected; that every material decision and transition is evidenced; that history survives change; and that the architecture can reconstruct not merely what it currently holds, but how that state came to exist and why it was permitted to be relied upon. Each record family resolves to exactly one authoritative maintainer, each historical view is derived rather than duplicated, each status represents one conceptual dimension, and each crosswalk demonstrates the obligation it claims.