KF-3005 · Lifecycle and Control Architecture

The State, Transition, Gate and Control Model of the Knowledge Foundry

Document Class: Reference Architecture · Parent Document: KF-3000 · Governed By: KF-3001 · Derived From: KF-2001, KF-2002, KF-3002, KF-3003 and KF-3004 · Status: Draft · Version: 0.2

Canon and Method (KF-1000 / KF-2001 / KF-2002)
        ↓
Architectural Rules (KF-3001)
        ↓
Capabilities and Services (KF-3002 / KF-3003)
        ↓
Governed Information (KF-3004)
        ↓
▸ Lifecycle and Control Architecture (KF-3005)
        ↓
Conformance, Authority and Traceability (KF-3007 / KF-3008 / KF-3009)
        ↓
Implementation (KF-4000)

Editorial Position

KF-3005 is the behavioural architecture of the Knowledge Foundry. The documents before it are largely structural: KF-3001 states what must remain true, KF-3002 what the architecture must be able to do, KF-3003 where logical responsibility resides, and KF-3004 what information exists and how it is preserved. KF-3005 defines how governed change is permitted and executed.

It is therefore neither a restatement of the nine-stage methodology lifecycle in KF-2001 nor a workflow specification for a particular implementation. KF-2001 defines the lifecycle method; KF-3005 defines the architectural machinery that makes that lifecycle enforceable.

Purpose

KF-3005 defines the behavioural architecture through which governed entities move between valid states. It specifies lifecycle domains; state machines; permitted transitions; transition-request semantics; gate compositions; reusable controls; execution and persistence rules; exception and degraded-state behaviour; recovery and reconciliation; concurrency and conflict handling; and control and transition evidence.

KF-3004 defines what governed information exists. KF-3005 defines how that information may change. KF-3005 introduces no new authoritative information classes; it uses the KF-3004 objects and governs their creation, update, correction, status change and historical preservation.

The document is centred on the transition rather than on the state. A state is a governed condition; a transition is the operation through which the architecture changes that condition. Accordingly, KF-3005 answers a single, narrow question:

Under what conditions may a governed entity move from one state to another; which authority may permit that movement; which controls must be satisfied; how is the transition executed; and what evidence must remain afterwards?

Alignment and Reconciliation Note

This document is reconciled against the nineteen-service catalogue shared by KF-3002 and the KF-3004 v0.2 record model (SVC-01 … SVC-19), in which the authoritative owners referenced here are: SVC-05 Justification (epistemic standing); SVC-06 Authority and Acceptance; SVC-08 Lifecycle and Transition; SVC-09 Version and Lineage; SVC-10 Release; SVC-12 Operationalisation; SVC-13 Application and Outcome; SVC-14 Retirement and Preservation; SVC-15 Provenance; SVC-16 Access and Integrity; SVC-17 Operating Condition and Exception; SVC-18 Conformance and Audit; SVC-19 Temporal Continuity. All service, record (KF-3004), invariant (KF-3001, INV-*) and interaction-constraint (IC-*) references in this document use that catalogue and the KF-3004 v0.2 record codes, including its §15.1 current-state / event-history rule and its §7.2 composite-decision rule.

Upstream caution. Where the scaffold named services that do not exist under a single owner — an “Epistemic Status Service,” a standalone “Release Service,” an “Operating Condition and Exception Service” — this document binds them to the frozen catalogue owners above. Any copy of KF-3003 that still enumerates only sixteen services predates this catalogue and should be read as superseded by the KF-3002 / KF-3004 v0.2 service model; the mismatch is an upstream KF-3003 versioning item, not a KF-3005 divergence.

Changes in v0.2

Relative to v0.1: the abnormal-condition vocabulary (failure, exception, violation, degradation, indeterminate, conflict) is consolidated into a single distinction table (§3); the “no single universal state machine” and “recovery is forward restoration, not historical erasure” principles are made explicit (§7, §44); “gates orchestrate reusable controls” is stated directly with a worked decomposition (§29); the three governed catalogues — Transition, Gate and Control — are named as an organising principle (§21); and the mis-labelled state-assertion clause is relocated to its proper place at the end of the state architecture (§20). Substantive content, identifiers and crosswalks from v0.1 are preserved.

Part I · Behavioural Architecture Foundations

1. Scope

KF-3005 governs changes involving Operational Knowledge ObjectsOperational Knowledge Object — the unit of design: a versioned representation together with its attached evidence, justification and acceptance-state (KF-1101). The system governs the object, never "knowledge itself". Vocabulary →; object versions; representations; epistemic standing; acceptance; release; stewardship and governance standing; actionable forms; applications; retirement; service operating condition; and conformance standing.

It excludes organisational workflow design; user-interface sequence; technology-specific transaction management; physical event-bus design; database locking; service deployment; detailed authority assignment (KF-3008); and assurance methodology (KF-3007).

2. Core Behavioural Concepts

2.1 Lifecycle — the permitted broad phases through which a governed entity may pass. 2.2 State — the effective governed condition of one entity within one state machine. 2.3 Transition — a governed operation attempting to move an entity from a valid source state to a permitted target state. 2.4 Gate — the authoritative decision composition determining whether a proposed transition may execute. 2.5 Control — a reusable mechanism that validates, prevents, detects, constrains, records or evidences one condition required by a gate or transition. 2.6 Trigger — an event, request, decision, elapsed period or condition initiating consideration of a transition. 2.7 Transition Request — the governed proposal to perform a specific transition on an identified entity. 2.8 Exception — a formally approved, bounded departure from normal control behaviour that does not violate an invariant. 2.9 Failure — an unsuccessful attempt to execute an otherwise valid operation. 2.10 Violation — a breach of a 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 →, invariant or mandatory interaction constraint. 2.11 Recovery — the governed restoration of architectural consistency following interruption, failure, degradation or conflict.

The five terms are canonical throughout KF-3005 and subsequent documents:

Lifecycle    defines the permitted journey
State        records the present condition
Transition   attempts governed change
Gate         decides whether change may proceed
Control      establishes whether required conditions hold

3. Abnormal Conditions

The architecture distinguishes six conditions that must never be silently collapsed into one another. Each has different evidence, ownership and disposition.

Two rules govern the boundary between them. First, an exception cannot convert an invariant violation into conformance — an authorised departure and a breach of an invariant are different in kind, not degree. Second, an indeterminate condition is never treated as satisfied: it is surfaced, not resolved by default (see §30, §43).

4. Behavioural Grammar

The signature behavioural sequence of KF-3005 is centred on the transition — the transition, not the state, is the unit of governed change:

Trigger → Transition Request → Entity and Current-State Resolution
→ Transition Eligibility → Required Evidence Assembly
→ Authority and Permission Validation → Control Execution → Gate Decision
→ Transition Execution → Authoritative State Update → Record Persistence
→ Event Publication → Conformance Evidence

5. Behavioural Invariants

Every transition must preserve: (1) the affected entity is uniquely identified; (2) the authoritative current state is resolved; (3) the transition is legally permitted by the applicable state machine; (4) required evidence is available or explicitly indeterminate; (5) applicable permission and authority are valid; (6) gate controls are executed; (7) Gate Decision and Transition Records are bound to one transition identifier; (8) no completed transition is partially recorded; (9) prior history remains recoverable; (10) affected services receive the resulting event; (11) failures and indeterminate outcomes remain visible; (12) conformance evidence is produced; (13) no transition bypasses a protected invariant; (14) semantic reversal does not erase the original transition.

6. Behavioural Specification Types

KF-3005 defines four specification types: State-Machine Specification (permitted states and transitions for one entity class); Transition Specification (one governed state change); Gate Specification (the decision composition controlling one or more transitions); Control Specification (one reusable validation or enforcement mechanism).

Part II · Lifecycle Domain Architecture

7. No Single Universal State Machine

The architecture defines no single universal state machine. KF-3004 has already established that several state dimensions remain distinct, and KF-3005 preserves that separation: each governed condition belongs to its own state machine, and an entity may occupy states across several machines simultaneously. None of these states silently determines another. For one Operational Knowledge Object at one instant:

Object lifecycle state:   Operational
Version status:           Released
Epistemic standing:       Supported but contested
Actionable-form status:   Restricted
Operating condition:      Degraded
Conformance status:       Exception open

Each of the six values above is owned by a different authoritative service and changes only through its own governed transition.

8. Lifecycle Domains

KF-3005 defines several related but independent lifecycle domains, each with an authoritative state service drawn from the frozen KF-3003 catalogue.

9. Cross-Domain Coordination

A transition in one domain may trigger evaluation in another but does not silently alter another domain’s state. Acceptance may enable consideration of release but does not create release; release withdrawal may suspend actionable-form eligibility but does not alter epistemic standing; weakened epistemic standing may trigger review or suspension but does not itself execute either; retirement removes operational eligibility but preserves history and may require related release and form withdrawals; a degraded operating condition may block a transition without changing the object’s epistemic state.

Part III · State Architecture

10. State-Machine Specification

Each state machine is defined through: identifier; governed entity; purpose; authoritative state record; authoritative service; permitted states; initial state; terminal states; permitted transitions; prohibited transitions; state-entry and state-exit conditions; cross-domain effects; historical-reconstruction rule; conformance test.

11. SM-OBJ · Operational Knowledge Object Lifecycle

Authoritative: SVC-08; record LIF-01.

States: Candidate → Registered → Structured → Under Evaluation → Justified → Accepted → Operational; with Suspended, Evolving, Retired and Historical.

Key transitions: Register, Structure, Begin Evaluation, Justify, Accept, Operationalise, Suspend, Evolve, Retire, Historicise, Reactivate.

Cross-domain: Operational status depends on an active release (SM-REL) but does not equal it.

Editorial note (retained): the final state list must be derived carefully from KF-2001 and KF-3004; some terms may ultimately be represented as stage participation rather than durable states. This machine must remain aligned with KF-2001 while distinguishing architectural state from method-stage activity.

12. SM-VER · Object Version State

Authoritative: SVC-09; record VER-01.

States: Draft → Established → Under Evaluation → Justified → Accepted → Released; with Superseded, Withdrawn, Historical.

A version may remain Established but unreleased. Creating a new version does not alter another version’s release status unless a separate transition occurs.

13. SM-EPS · Epistemic Standing

Authoritative: SVC-05; record EPS-01.

A governed standing model, not a workflow. Values: Unsupported, Provisionally Supported, Supported, Strongly Supported, Weakened, Indeterminate. Contestation (EPS-03) and assessment progression (EVA-02) remain separate dimensions and are not encoded here.

14. SM-ACC · Acceptance State

Authoritative: SVC-06; record ACC-01.

States: Not Submitted, Pending, Accepted, Provisionally Accepted, Refused, Expired, Withdrawn, Superseded. Acceptance applies to a defined version, scope and effective period.

15. SM-REL · Release State

Authoritative: SVC-10; record REL-01 / REL-02.

States: Candidate, Pending, Active, Restricted, Suspended, Withdrawn, Expired, Superseded. Release state is independent of version state and object lifecycle state.

16. SM-ACT · Actionable Form State

Authoritative: SVC-12; record ACT-01 / ACT-04.

States: Draft, Under Review, Eligible, Restricted, Suspended, Withdrawn, Superseded, Historical.

17. SM-APP · Material Application State

Authoritative: SVC-13; record APP-01.

States: Requested, Eligibility Pending, Authorised, In Progress, Completed, Failed, Aborted, Reconciled.

18. SM-OPR · Operating Condition

Authoritative: SVC-17; record OPR-01.

States: Operational, Degraded, Unavailable, Pending, Failed, Indeterminate, Recovering, Recovered.

19. SM-CNF · Conformance Standing

Authoritative: SVC-18; record CNF-01 / CNF-05.

States: Not Assessed, Assessment Pending, Conformant, Conformant with Approved Exception, Indeterminate, Non-Conformant, Remediation in Progress, Remediated.

20. State-Assertion Rule (applying KF-3004 §15.1)

A transition record preserves the historical act; a state record represents the effective current condition; both are established consistently through one governed transition operation. A discrepancy between transition history and current state must produce an integrity or indeterminate condition (a Conflict, per §3). Consistent with §7, none of the state dimensions silently determines another: an object may simultaneously be Operational, Released, Supported-but-Contested, Restricted (form), Degraded (condition) and Exception-Open (conformance).

Part IV · Transition Architecture

21. Three Governed Catalogues

KF-3005 defines its permitted behaviour through three distinct catalogues, deliberately kept separate rather than flattened into one control list:

• the Transition Catalogue (§27) — the permitted governed changes;
• the Gate Catalogue (§31) — the decision compositions controlling those changes;
• the Control Pattern Library (Part VI) — the reusable checks and enforcement mechanisms invoked by gates and transitions.

Separation is what allows one control to be reused across many gates, and one gate across many transitions.

22. Transition Specification

Every governed transition is specified through: transition identifier; name; purpose; governed entity; source state; target state; permitted trigger; preconditions; required evidence; required authority class; required permissions; applicable gate; required controls; authoritative executing service; collaborating services; records created or changed; execution atomicity; events published; cross-domain effects; failure behaviour; recovery behaviour; conformance evidence.

23. Transition Request

Every request identifies: request identity; transition type; governed entity; source state claimed; target state requested; trigger; requesting actor or service; authority basis where applicable; supporting evidence; requested effective time; urgency; related exception; concurrency token or state reference. A request does not authorise or execute the transition.

24. Transition Eligibility

A transition is eligible for gate evaluation only where: the entity exists; the source state is authoritative and current; the transition is permitted by the state machine; required evidence can be resolved; required authority and permissions are identifiable; no unresolved state conflict prevents assessment; and the applicable operating-condition policy permits evaluation.

25. Transition Atomicity

A governed transition is architecturally atomic: it has one indivisible governed outcome — Completed or Not Completed. A completed transition establishes consistently: Gate Decision Record; Transition Record; resulting authoritative state; required status records; material provenance; event-publication record; conformance evidence.

A transition must never leave the architecture in a state where a gate says pass but the state did not change; the state changed but no transition record exists; a release was created but its acceptance reference is missing; or one service believes an object suspended while another treats it as active. A transition that cannot establish all required effects must abort, remain pending, enter recovery, or complete under an explicitly defined bounded-degradation pattern. It must not appear completed while required records remain absent.

Atomicity does not mandate a single database transaction. Where technical atomicity is impossible, the architecture must define provisional state, recovery obligations, reconciliation, bounded duration and compensating controls.

26. Idempotency and Replay

A repeated request carrying the same transition identity must not produce duplicate transitions. Replay distinguishes continuation of an interrupted transition; retry after failure; deliberate repetition of a prior transition; and semantic re-execution under new evidence.

27. Transition Catalogue (provisional)

Domain-sensitive identifiers; representative, not exhaustive.

Part V · Gate Architecture

28. Gate Specification

Each gate is specified through: identifier; name; purpose; applicable transitions; required entry state; required information objects; required authority; required controls; decision composition; permitted decision outcomes; blocking conditions; exception rules; records produced; events published; conformance evidence.

Assurance-class parameterisation. A gate’s exit criteria, the depth of evidence it requires, and the review or authority it demands are applied 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), resolved at the release / scope-of-reliance to which the class attaches and enforced by KF-3001 IC-23. A higher class raises required rigour; it does not add new gates. The gate’s protection of the six ungraded 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 → is identical at every class — only the depth above that floor scales.

29. Gates Orchestrate Controls

A gate is not one large control. A gate orchestrates several reusable controls, each of which establishes whether one required condition holds. This is what permits the same control to be reused across several gates. The Release Gate illustrates the pattern:

GATE-REL-01 · Release Gate
    ├── State Eligibility Control          (CTRL-STA-01)
    ├── Acceptance Validity Control        (CTRL-ACC-01)
    ├── Authority Validation Control       (CTRL-AUT-01)
    ├── Dependency Clearance Control       (CTRL-DEP-01)
    ├── Governance Standing Control        (CTRL-STW-01 / CTRL-REV-01)
    ├── Operating Condition Control        (CTRL-OPR-01)
    ├── Exception Control                  (CTRL-EXC-01)
    └── Provenance Completeness Control    (CTRL-PRO-01)

The gate composes the results of these controls into one decision; it does not re-implement them. The full gate-to-control mapping is given in §56.

30. Standard Gate Outcomes

Every gate supports, where applicable: Pass, Fail, Return, Pending, Indeterminate, Pass with Approved Restriction. An outcome of Indeterminate is never silently treated as Pass.

31. Gate Catalogue (provisional)

Part VI · Control Pattern Library

32. Control Specification

Each control is specified through: identifier; name; type; purpose; input condition; information required; executing service; authority dependency; evaluation logic; possible results; failure behaviour; evidence produced; protected invariants; enforced interaction constraints; reused by gates; conformance test.

Class-graded strength. Where a control’s evaluation depends on a threshold — evidence sufficiency, review independence, monitoring frequency — that threshold scales with the object’s assurance class (KF-2003) under IC-23. A control that protects an invariant enforces it at every class without relaxation; a control that discharges a graded obligation applies the minimum for the object’s class. The same control is thereby reused across classes at different depths, just as it is reused across gates (§29).

33. Control Types

Preventive (blocks an invalid action); Detective (identifies an invalid, missing or degraded condition); Corrective (returns the architecture to a governed condition); Evidentiary (produces inspectable proof); Historical (preserves prior states and reconstructability); Directive (defines required behaviour or routing).

34. Control Families

Family A · Identity and State — CTRL-ID-01 Object Identity Resolution; CTRL-ID-02 Duplicate and Prior-Object Detection; CTRL-STA-01 Authoritative Current-State Validation; CTRL-STA-02 Transition Legality Validation; CTRL-STA-03 State-Conflict Detection; CTRL-VER-01 Version Immutability; CTRL-LIN-01 Lineage Integrity.

Family B · Evidence and Warrant — CTRL-EVD-01 Required Evidence Presence; CTRL-EVD-02 Evidence Availability; CTRL-EVD-03 Counter-Evidence Visibility; CTRL-EVA-01 Evaluation Completion; CTRL-JUS-01 Justification Completeness; CTRL-EPS-01 Epistemic Standing Validation; CTRL-WAR-01 Warrant-Link Preservation.

Family C · Authority and Governance — CTRL-AUT-01 Authority Mandate Validation; CTRL-AUT-02 Delegation Validity; CTRL-PRM-01 Permission Validation; CTRL-ACC-01 Acceptance Validity; CTRL-STW-01 Stewardship Validation; CTRL-REV-01 Review Currency; CTRL-SEG-01 Separation-of-Duties Validation; CTRL-GOV-01 Governance-Exception Validation.

Family D · Release and Operational — CTRL-REL-01 Release Eligibility; CTRL-DEP-01 Dependency Impact Clearance; CTRL-ACT-01 Actionable-Form Eligibility; CTRL-APP-01 Application Eligibility; CTRL-CTX-01 Use-Context Compatibility; CTRL-EXP-01 Explainability Requirement; CTRL-OUT-01 Outcome Capture Requirement.

Family E · Integrity, Condition and Assurance — CTRL-PRO-01 Provenance Completeness; CTRL-INT-01 Record Integrity; CTRL-TMP-01 Effective-Time Validation; CTRL-OPR-01 Operating-Condition Validation; CTRL-EXC-01 Blocking-Exception Check; CTRL-ATM-01 Transition Atomicity; CTRL-EVT-01 Event Publication; CTRL-CNF-01 Conformance-Evidence Recording; CTRL-AUD-01 Independent-Audit Visibility.

Part VII · Transition Pattern Library

35. Standard Transition Pattern

Request → Resolve Entity and Current State → Validate Transition Legality
→ Resolve Required Evidence → Validate Permission and Authority
→ Validate Dependencies and Operating Condition → Execute Gate Controls
→ Record Gate Decision → Execute Transition → Persist State and Transition Records
→ Publish Events → Record Conformance Evidence

The final step, Record Conformance Evidence, is the emission of evidence the preceding steps already produced — the gate decision, the transition record, the published events — not the separate authoring of an evidence artefact. The governed act is its own evidence (KF-3001 IC-24; KF-3004 §5.2). A distinct artefact is added only where the act’s own records cannot carry the required proof.

36. Specialised Patterns

Creation (creates a governed entity where none existed); Promotion (moves an entity into a more operationally eligible state after satisfying additional obligations — candidate→evaluated, accepted→released, provisional form→eligible); Restriction (reduces permitted reliance without removing all eligibility); Suspension (temporarily removes eligibility pending review, recovery or correction); Withdrawal (ends a release, acceptance or form eligibility without retiring the object); Supersession (replaces a version, release, representation or form with a successor, preserving lineage); Correction (creates a governed correction without erasing the original); Retirement (ends active eligibility of the enduring object while preserving history); Reactivation (routes a retired or suspended entity through renewed evolution before eligibility is restored); Recovery (restores a failed, interrupted or degraded operation to a consistent governed condition).

Part VIII · Composite Decision Architecture

37. Composite Decisions

A gate decision may depend on several independently authoritative conditions. The gate records references to those authoritative records rather than reproducing them (KF-3004 §7.2), so no gate becomes a competing source of truth.

38. Release Decision Composition (GATE-REL-01)

Eligible Object Version + Valid Justification + Applicable Epistemic Standing
+ Valid Acceptance + Applicable Authority + Assigned Steward
+ Dependency Clearance + Valid Operating Condition + No Blocking Exception
+ Required Provenance → Release Gate Decision

39. Application Eligibility Composition (GATE-APP-01)

Active Object + Eligible Actionable Form + Valid Release + Compatible Use Context
+ Current Governance Standing + Applicable Permission + Required Human Oversight
+ Acceptable Operating Condition + No Blocking Restriction → Application Eligibility Decision

40. Retirement Decision Composition (GATE-RET-01)

Valid Retirement Reason + Applicable Authority + Dependency Disposition
+ Successor or Supersession Handling + Form and Release Withdrawal
+ Preservation Plan + Historical Continuity → Retirement Gate Decision

Part IX · Exception and Degraded-State Architecture

41. Exception Classes

Operational Exception (a bounded departure affecting execution without changing architectural obligations); Governance Exception (a formally authorised, time-limited departure from a governance practice where no invariant is violated); Architectural Variation (a conforming alternative design); Architectural Violation (a breach of a mandatory invariant or constraint); Indeterminate Condition (validity cannot currently be established). Consistent with §3, an exception cannot convert an invariant violation into conformance.

42. Exception Specification

Each exception records: identity; affected transition / gate / control; scope; reason; authority; effective period; compensating controls; prohibited consequences; monitoring; expiry; review; closure; conformance effect.

43. Fail-Open and Fail-Closed Behaviour

Every control and gate declares whether failure or indeterminate standing causes fail-closed, bounded degraded operation, manual review, temporary restriction, retry, suspension or abort. Fail-open behaviour requires explicit justification and bounded scope. The default for governance-critical operations is fail-closed.

Part X · Recovery and Reconciliation Architecture

44. Recovery Is Forward Restoration, Not Historical Erasure

Recovery restores permitted operation; it does not rewrite the past. In a governed architecture, “rollback” must not erase the attempted transition, the gate decision, the failed action, intermediate records or recovery activity. A semantic reversal adds to history — it is a new governed transition returning an entity to an earlier operational condition, not a deletion of the original act. Accordingly the architecture separates technical rollback (transactional consistency) from semantic reversal (a new restoring transition), and both from reinstatement (restoration of eligibility after revalidation), replay (re-execution of an interrupted or deferred operation) and reconciliation (detection and correction of inconsistency between services or records).

45. Recovery Modes

Abort (terminate without changing governed state); Retry (repeat an idempotent operation); Replay (continue or re-execute from governed event history); Technical Rollback (restore transactional consistency without erasing evidence of the attempt); Semantic Reversal (a new transition restoring an earlier operational condition — it adds to history); Reconciliation (compare authoritative records and repair inconsistency); Revalidation (reassess whether prior eligibility remains valid); Reinstatement (restore eligibility after successful revalidation and gate approval).

46. Recovery Requirements

Recovery must preserve the failed or interrupted attempt; identify the last consistent state; prevent duplicate execution; reconcile authoritative services; preserve temporal order; record compensating action; validate post-recovery invariants; publish recovery events; and produce conformance evidence.

Part XI · Concurrency and Conflict Architecture

47. Concurrency Principles

1. A transition evaluates authoritative state immediately before execution. (2) A stale source-state reference invalidates the request. (3) Conflicting transitions are serialised, rejected or explicitly reconciled. (4) A future-effective decision is reconsidered where a blocking event occurs before effect. (5) No service assumes a previously retrieved eligibility condition remains valid indefinitely. (6) Cross-service state changes are reconciled through authoritative events and transition identifiers. The architecture requires transition identifiers, state-version or concurrency tokens, effective-time checks, immediate pre-execution revalidation, conflict detection, explicit precedence and idempotent retry — without prescribing a locking technology.

48. Conflict Types

Concurrent version changes; acceptance withdrawal during release; release withdrawal during application; retirement during pending evolution; conflicting authority decisions; stewardship transfer during approval; retrospective correction affecting a completed decision; dependency discovery after release; service-state disagreement; event-ordering ambiguity.

49. Conflict Disposition

Reject the later request; prioritise mandatory suspension; queue for reassessment; merge non-conflicting changes; create a branch; suspend operational use; escalate to accountable authority; mark indeterminate; or reconcile after recovery.

Part XII · Control and Transition Conformance

50. Transition Conformance

Source and target states permitted; required controls executed; applicable gate produced a valid decision; authority and permission valid; records complete and consistent; atomicity preserved; events published; history recoverable; no invariant violated; conformance evidence independently inspectable.

51. Gate Conformance

Required conditions explicit; controls identified; evidence authoritative and current; decision outcomes distinguishable; indeterminate conditions visible; exception handling bounded; Gate Decision Records complete; decision composition reconstructable.

52. Control Conformance

Purpose and scope defined; required inputs available; evaluation logic inspectable; outcomes recorded; failure behaviour defined; protected invariants identifiable; evidence independently testable.

53. Behavioural Reconstruction Test

For any material transition, the architecture must reconstruct:

Trigger → Transition Request → Source State → Evidence and Authority
→ Controls Executed → Gate Decision → Transition Execution → Resulting State
→ Records Persisted → Events Published → Conformance Evidence

Part XIII · Crosswalks

54. State-Machine-to-Service Crosswalk

55. Transition-to-Gate Crosswalk

56. Gate-to-Control Crosswalk

57. Control-to-Invariant Crosswalk

58. Control-to-Interaction-Constraint Crosswalk

59. Gate-to-Information Crosswalk

60. Transition-to-Authority Crosswalk (abstract classes for KF-3008)

61. Transition-to-Conformance-Evidence Crosswalk (for KF-3007)

Every material transition produces, at minimum: Gate Decision Record (GAT-01); Transition Record (TRN-01); the resulting authoritative state record; provenance (PRO-01); an event-publication record; and conformance evidence (CNF-01 / CNF-02). KF-3007 defines how this evidence is sampled, tested and judged.

62. Lifecycle-to-Capability Crosswalk

63. Lifecycle-to-Service Crosswalk

Part XIV · Relationship to Subsequent Documents

KF-3008 defines the authority and accountability model — authority sources, delegation, accountable-body composition, separation of duties, mandate validity and role assignment — satisfying the abstract authority classes KF-3005 identifies in the Transition-to-Authority Crosswalk (§60). KF-3005 references authority only in abstract form (Required Authority Class, Required Decision Role, Required Separation Condition); KF-3008 defines who may occupy those roles.

KF-3007 defines how the evidence produced by state changes, gates and controls (§61) is assessed — sampling, assessment procedure, assurance independence, severity and conformance judgement. KF-3005 defines what evidence must exist; KF-3007 defines how it is tested.

KF-3009 maps every state, transition, gate and control back to the Canon, lifecycle, practice, capability, service and information obligations from which it derives.

KF-4000 may implement this behavioural architecture through state machines, workflow engines, rules engines, transaction managers, event-driven architectures, human approval processes, AI-agent orchestration, manually maintained registers, or combinations. It may not bypass a required gate; collapse gate decision and transition execution; treat indeterminate evidence as satisfied; permit silent state mutation; erase failed transitions or recovery history; infer authority from permission; release or apply ineligible knowledge; create conflicting authoritative states; make transition history unreconstructable; or substitute automation for accountability.

Closing Statement

KF-3005 defines the governed behaviour of the Knowledge Foundry architecture. It establishes how state may change, how transitions are requested and executed, how gates compose authoritative decisions from independently owned records, how controls preserve invariants, how failures and exceptions remain visible, and how every material change leaves sufficient evidence for historical reconstruction and assurance. KF-3004 defines the architecture’s memory; KF-3005 defines the disciplined behaviour through which that memory is allowed to change.