KF-2001 · Operational Knowledge Object Lifecycle

The canonical engineering lifecycle of a governed knowledge object, from capture to retirement

Methodology · Draft · v0.1 · 23 min read

Principle (KF-1000)  →  ▸ Method (KF-2000)  →  Architecture (KF-3000)  →  Implementation (KF-4000)

Purpose

This document defines the canonical engineering lifecycle through which an 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 → evolves from initial capture to eventual retirement. It is the common engineering model beneath all Knowledge Foundry methods; the methods that follow in KF-2000 act on the stages defined here.

The lifecycle models the evolution of justified knowledge, not the storage of information. A document-management system versions files and advances a record whenever it is saved; this lifecycle advances an object only when the obligations of its current stage are discharged. The difference is the gate. In a storage system a transition is a save event; here a transition is an act of warrant, and an object that has not earned the warrant of its stage does not advance, however complete it looks.

How This Document Sits in the Programme

KF-2001 is a Method-level document. It says how the discipline acts on the principles fixed by the Canon (KF-1000); it does not restate or revise them. Consistent with the four-level separation, this document names no technologies, stores or products — those are architecture (KF-3000) — and no deployments — those are implementation (KF-4000). Where a stage discharges 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 →, the principle is cited in a single Canon basis line; the authoritative stage-to-principle mapping is KF-2002, and is not duplicated here.

Method, Not Workflow

This lifecycle specifies the engineering obligations associated with each stage — what must be true for an object to advance — not the workflow by which any particular organisation satisfies them. Method fixes the obligation; workflow fixes the order of work, the tools, the hand-offs and the cadence by which a given deployment meets it. Workflow therefore belongs to implementation (KF-4000), not here.

Conformance is not a matter of following a prescribed sequence of steps. It is whether, for every object, every obligation and every lifecycle invariantLifecycle 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 met. Two organisations may run very different workflows — one manual and deliberative, another largely automated — and both conform to this lifecycle, provided no gate is passed unearned and no invariant is broken.

The Object and Its States

The object under management is an Operational Knowledge Object throughout its life. What the lifecycle changes is its state, not its identity. The stage outputs below name successive states of one object — Candidate, Structured, Evaluated, Justified, Accepted, Operational, and so on — not distinct objects. An object becomes an Operational Knowledge Object in the full Canon sense once it carries representation, evidence, justification and an acceptance-state; the early stages assemble those attachments onto an object that already holds a stable identity.

Terminology note (flagged design decision). “Operationalise” (Stage 5) makes an object’s knowledge actionable; it is not the same word as “Operational Knowledge Object,” which names the artefact across its whole life. Where the two could be confused, this document calls the Stage-5 result the object’s actionable form and reserves “Operational Knowledge Object” for the artefact. The stage names from the source model are preserved unchanged.

Lifecycle Overview

Worked example. KF-5001 walks a single Operational Knowledge Object — a four-day-week Knowledge Brief — through every stage below, from Capture to Supersession.

Capture
   ↓
Structure
   ↓
Evaluate
   ↓
Justify
   ↓
══ Accept ══   (an authority certifies the object — a named transition, not a stage)
   ↓
Operationalise
   ↓
Govern
   ↓
Apply
   ↓
Evolve
   ↓
Retire

Each stage is a distinct engineering responsibility with a defined entry condition and an exit gate. An object progresses only when the exit gate of its current stage is satisfied; until then it remains in place or returns to an earlier stage. The stages are not all of one kind: Capture through Justify construct the object; Accept is a decision by authority, not engineering work, and is modelled as a transition; Operationalise realises it; Govern holds it in custody; Apply uses it; Evolve changes it; Retire closes it. Application is the one step that does not transform the object — it is an operational context in which the object is used and from which evidence returns.

The sequence above is the principal path, not the only path. As evidence changes, an object may return to an earlier stage, and from several steps it may pass directly to Retire. The lifecycle is a loop, not a ladder — a property inherited from the Landscape’s account of the knowledge object and made operational here through the return paths defined below.

The Three Dimensions of Every Transition

A workflow advances one property: a status. This lifecycle advances three at once. Every transition changes not only the state of the object, but the evidence attached to it and the governance posture it has achieved. These three dimensions are independent — they answer different questions — and reading the lifecycle as only a sequence of states hides two-thirds of what each transition does.

• State — what the object is: the label that says how far it has progressed.
• Evidence — what is attached to the object: the accumulating record that travels with it.
• Governance posture — what is assured about the object: the governance property each step secures.

Two features of this table matter. First, the three columns advance at different times: Apply adds evidence and governance assurance without changing the object’s state, which is precisely why application is a different kind of thing from the construction stages. Second, each column can be read on its own as a coherent progression — a reviewer auditing evidence need not trace state, and a reviewer auditing governance need not trace either. The lifecycle is richer than a pipeline because it is really three pipelines advancing on one object.

The Nine Stages

Stage 1 — Capture

Purpose. Admit candidate information into the system. Capture is deliberately permissive: the aim is to bring material in, not yet to judge it. Nothing captured is trusted, and nothing captured is knowledge; everything enters as a candidate whose status must be earned downstream.

The one obligation that cannot be deferred at capture is origin. Provenance can be recorded now but rarely reconstructed later: the moment a source is detached from its content, the object’s history is compromised for the rest of its life. Capture therefore records where the material came from as a condition of entry, even while deferring every question of quality and warrant.

Typical inputs. Documents; research papers; interviews; AI outputs; meeting notes; regulations; datasets; observations.

Entry condition. Material is presented to the system. Activities. Intake; source identification; provenance seeding; assignment of a candidate identifier. Exit gate. The candidate is recorded together with its origin. Output state. Candidate. Accountable role. Contributor. Key question. What has entered the system? Canon basis. Provenance invariant; Principle I (the object, not knowledge, is what enters).

Stage 2 — Structure

Purpose. Transform raw, opaque input into a structured object that can be reasoned about. Structuring is what makes everything downstream possible: an object that cannot be inspected cannot be evaluated, justified, explained or governed. The stage confers a stable identity and an inspectable form.

Entry condition. A Candidate with recorded origin. Activities. Decomposition; metadata assignment; semantic typing; relationship identification; provenance recording. Exit gate. The object has a stable identity, a semantic type, its relationships, and a provenance record — that is, it is inspectable. Output state. Structured. Accountable role. Knowledge Engineer. Key question. What exactly is this object? Canon basis. Inspectability invariant; Principle I.

Stage 3 — Evaluate

Purpose. Assess quality before any question of belief is raised. Evaluation asks whether the object is good enough to be worth justifying — a different and prior question to why it should be believed. It is the first gate that can stop progression: an object may pass, be returned for restructuring, or be rejected outright.

Entry condition. A Structured object. Activities. Source assessment; evidence-quality assessment; confidence estimation; consistency and completeness checks. Exit gate. A quality verdict — pass, return, or reject — is recorded with its reasons. Output state. Evaluated. Accountable role. Evaluator. Key question. Should this object be trusted? Canon basis. Principle IV (the Validation/Quality primitive).

Stage 4 — Justify

Purpose. Establish epistemic legitimacy. This is the epistemic core of the lifecycle: the stage at which an object earns the standing to be called knowledge. Justification attaches the reasons for belief to the object and makes them inspectable. Counter-evidence is recorded as a matter of obligation, not option — an object justified only by the evidence that supports it has not been justified, it has been advocated.

A system can engineer justification even though it cannot engineer truth; justification, not truth, is the standard every transition is held to.

Entry condition. An Evaluated object that passed. Activities. Assembly of supporting evidence; assembly of counter-evidence; statement of rationale; statement of assumptions; end-to-end traceability. Exit gate. The object carries an inspectable justification: supporting and counter-evidence, rationale, assumptions, and traceability to source. Output state. Justified. Accountable role. Evaluator (with domain authority as required). Key question. Why should this be believed? Canon basis. Principle VIII; Principle IV; justification invariant.

══ The Acceptance Transition ══ (Justify → Operationalise)

Acceptance is the act by which an identified authority certifies a justified object as fit to be relied upon. It is the single most consequential moment in the lifecycle, and it is deliberately not a stage: nothing is transformed, no work is performed on the object. It is a decision about the object — the point at which human authority admits a justified representation into operational use. For that reason it is modelled as a named transition, a gate, rather than an engineering stage. This mirrors the treatment of Application below: both are things that happen to a governed object without being engineering transformations of it, and naming them honestly keeps the nine stages purely about work performed on the object.

Acceptance is where the object acquires the acceptance-state that the Canon requires of a full Operational Knowledge Object (KF-1001). Until it is accepted, an object may be perfectly justified and still have no standing to be relied upon; justification establishes why it may be believed, acceptance establishes that we will act on it. The two are distinct, and conflating them is the failure this transition exists to prevent.

Who acts. An Authority — an identified person or body with the right to certify knowledge for the community that will use it. Requires. A Justified object with inspectable justification. Produces. An acceptance-state recorded against the object — accepted, provisionally accepted, or refused — attributed to the authority and dated. On acceptance the object proceeds to Operationalise; on refusal it returns to Justify or Evaluate with reasons. Key question. On whose authority will we rely on this? Canon basis. Principle III (knowledge becomes capability through collective authorisation); Principle IV (the Authority primitive); human-accountability invariant.

Stage 5 — Operationalise

Purpose. Make accepted knowledge usable. Operationalisation converts an accepted object into an actionable form — the shape in which it can be applied in decisions, reasoning or automation. The binding constraint is that the actionable form must remain linked to its justification. A playbook, rule or prompt that has been severed from the evidence and reasoning that warrant it is ungoverned knowledge in use, and is the failure mode this stage exists to prevent.

Entry condition. An Accepted object (see The Acceptance Transition above). Activities. Derivation of decision rules, playbooks, patterns, prompts, procedures or models; linkage of each to the underlying justification. Exit gate. An actionable form exists and is traceably linked to its justification. Output state. Operational (actionable). Accountable role. Knowledge Engineer. Key question. How can this knowledge be used? Canon basis. Principle II (lifecycle); Principle I.

Stage 6 — Govern

Purpose. Maintain legitimacy through time. Acceptance is not permanent, and Govern is the standing machinery that keeps an operational object legitimate as its context changes: ownership, review cycles, approvals, versioning, provenance upkeep and policy compliance.

Govern is a stage, but governance is not confined to it. The Governance PrimitivesGovernance Primitive — one of the six operations by which warrant is conferred: evidence, authority, provenance, validation, versioning, reversibility (KF-1104). Vocabulary → operate throughout the lifecycle — provenance from Capture, validation at Evaluate, justification at Justify, authority at Accept. Stage 6 does not introduce governance; it makes it continuous, and it names the person or body answerable for the object from this point forward.

Entry condition. An Operational object. Activities. Assignment of ownership; scheduling of review cycles; approval workflows; version control; provenance maintenance; policy-compliance checks. Exit gate. Ownership is assigned and a review cycle is in force. (This gate is standing, not one-off: it must remain satisfied for the object to stay operational.) Output state. Governed. Accountable role. Steward (owner). Key question. Who is accountable? Canon basis. Principle IV; Principle VII; human-accountability invariant.

Stage 7 — Apply

Purpose. Use the governed object in the practice it was built to serve. Application is different in kind from every stage before it: it does not transform the object, it uses it. Its engineering value is that it is the lifecycle’s principal source of new evidence — the outcomes of use are the truest test of whether the knowledge is fit — and it is therefore the principal trigger for evolution. The lifecycle’s working rhythm is use, observe, improve, and Apply is the “use” and “observe” of that rhythm.

Because application does not change the object’s state, an applied object remains Governed; what changes is the evidence attached to it (operational outcomes) and what is assured about it (its accountability in use). Outcomes feed forward into Evolve, or, where use shows the object is no longer needed, into Retire.

Entry condition. A Governed object. Activities. Use in human decisions, AI reasoning, automation and organisational workflows; use in teaching and advisory work; capture of outcomes. Exit gate. Outcomes are captured and attached to the object as feedback. Output state. Operational Outcomes (feedback into Evolve or Retire); the object remains Governed. Accountable role. User. Key question. Did the knowledge produce value? Canon basis. Principle IX (knowledge must remain explainable in use); Principle III.

Stage 8 — Evolve

Purpose. Allow controlled improvement. Change is the default condition of knowledge, and Evolve is where change is performed as a first-class, justified operation rather than an untracked edit. Every change produces a new version; the prior version is preserved, never overwritten. A change is itself a transition, and so carries its own justification and provenance.

Evolution is triggered principally by the outcomes of Application, and also by new external evidence, competing claims or a scheduled review — so an object may enter Evolve from Apply or directly from Govern. It takes several forms: amendment in the light of new evidence; adjudication of competing claims; supersession of one object by another; branching for divergent contexts; and consolidation of several objects into one. Each returns the object to the appropriate earlier stage for re-evaluation, re-justification and re-acceptance before its new version can be relied upon.

Entry condition. A Governed object with a change trigger (application outcomes, new evidence, a competing claim, or a scheduled review). Activities. Amendment; incorporation of new evidence; adjudication of competing claims; supersession; branching; consolidation. Exit gate. A new version is produced under recorded justification and provenance, with the prior version retained. Output state. Next Version (which re-enters the lifecycle at Evaluate or Justify, and is re-accepted before returning to operational use). Accountable role. Steward, with the Evaluator and Authority as required. Key question. What has changed? Canon basis. Principle X; Principle II; governed-evolution invariant.

Stage 9 — Retire

Purpose. Conclude the operational life of the object. Retirement is a change of state, not a deletion: the object leaves active use but its record — content, justification, provenance and history — is preserved. An object is retired because it is obsolete, superseded, merged, archived or withdrawn; the reason is recorded, because the fact of retirement is itself part of the knowledge history a later reader may need.

Retirement is reversible in principle. If evidence changes such that a retired object regains relevance — for example, a superseding object is itself withdrawn — the historical object can be reactivated through Evolve, with its provenance intact.

Entry condition. A retirement reason holds for a Governed or applied object. Reasons. Obsolete; superseded; merged; archived; withdrawn. Exit gate. The object is moved to the historical state, its retirement reason recorded and its history preserved. Output state. Historical. Accountable role. Steward. Key question. Why is this object no longer active? Canon basis. Principle VII (trust across time); Principle X.

Transitions and Return Paths

The principal path runs Capture → Retire, but the lifecycle is governed as a loop. Three kinds of non-forward transition are canonical.

Returns send an object back to an earlier stage when a gate cannot be met. Evaluate may return an object to Structure or Capture when it is ill-formed or its origin is inadequate. Justify may return an object to Evaluate when its justification fails. Acceptance may be refused, returning a justified object to Justify or Evaluate with the authority’s reasons — a refusal is as much a governed transition as an acceptance, and is recorded as one.

Evolution re-entry. Evolve re-enters the lifecycle at Evaluate or Justify, and its new version passes through the Acceptance transition again before returning to operational use. A new version re-earns its warrant and its authority; it does not inherit them.

Retirements may be reached from Govern, Apply or Evolve. An object that becomes obsolete, superseded or withdrawn passes directly to Retire without completing the forward path.

Every transition — forward, return, acceptance, refusal or retirement — is itself a governed act: it is recorded, attributed and justified. There are no silent transitions. This is what distinguishes the lifecycle from a workflow in which status simply advances: here, movement between states is the very thing being governed.

Engineering Events

States and transitions describe what the lifecycle does. Events describe what causes it to act. The lifecycle is, formally, a state machine with three distinct kinds of element:

• States — what an object is at a given moment (Candidate, Structured, Justified, Accepted, Governed, Historical …).
• Transitions — the governed moves between states (Accept, Return, Evolve, Retire …).
• Events — the occurrences that trigger a transition (new evidence, a scheduled review, a challenge …).

Events cause transitions; transitions produce new states:

State
   │
Engineering Event   (what happened)
   │
Transition          (the governed move it triggers)
   │
New State

Separating events from transitions matters for two reasons. First, it makes the model a clean state machine — the form over which later automated validation and orchestration operate. Second, it locates where automation is safe: an event may be raised by a human or by an agent, but the transition it triggers remains governed — attributable, justified, and, where authority is required, certified by a human. An AI recommendation is an event, not an acceptance; automation may propose, but the invariants still hold on whatever transition follows.

The canonical event types, and the transitions they typically trigger:

An event does not itself change an object; it obliges the system to perform — and govern — a transition. No event bypasses a gate.

Roles and Accountability

The lifecycle defines role responsibilities, not posts or systems; how they are staffed is an implementation concern (KF-4000). One person may hold several roles; a role may be held by several people. What the method fixes is that every stage has an accountable role, and that acceptance and stewardship are always held by an identifiable human authority — labour may be distributed across people and machines, but accountability may not be discharged into a substrate.

Lifecycle Invariants

The lifecycle principles below describe how the lifecycle behaves. The invariants here describe what must be true of an object at every instant, regardless of stage. An invariant is a continuously checkable property: an object that violates any invariant is non-conformant, whatever state it is in and however it reached it. These are the properties automated validation will assert, and the ground on which the Reference Architecture (KF-3000) is designed.

Six invariants hold across the whole lifecycle.

1. Single identity. Every Operational Knowledge Object has exactly one immutable identity for its entire life. Identity is assigned at Capture and is never reassigned, reused or mutated. Editing produces new versions under the same identity; branching, consolidation and supersession create successor objects with their own identities, linked to their predecessors. They do not split, merge or overwrite an existing identity. (Identity, version and lineage are distinct concerns, and KF-3000 realises them separately.)
2. Attributable transitions. Every state transition is attributable to an identified actor — a person, or an agent acting under a named human authority. No transition is anonymous.
3. Justified transitions. Every state transition carries a recorded justification. A transition without a recorded reason is not permitted, even when it is automatic.
4. Inspectable transitions. Every state transition is inspectable after the fact: what changed, why, by whom, and from which prior state can always be recovered.
5. Provenance always present. No operational state exists without a complete provenance chain back to origin. Provenance is a precondition of operational use, not an annotation added afterward.
6. Lineage preserved. Retirement, supersession and consolidation never destroy lineage. History is append-only; states are superseded, never erased.

Where an invariant appears to echo a principle — justification, for instance — the two do different work. The principle is the behavioural rule that a transition must earn its justification in order to proceed; the invariant is the checkable property that, once made, the transition carries that justification for all time. Principles govern progression; invariants govern conformance.

Invariants are ungraded. These six hold identically for every object, whatever its consequence or intended reliance. What does vary with reliance is the depth to which a gate’s obligations must be discharged — the strength of evaluation, the independence of review, the sufficiency of evidence. That depth is set by 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 →, defined in KF-2003 and attaching to the object’s scope of reliance at acceptance and release. An Exploratory object and a Consequential one cross the same gates and satisfy the same six invariants; the Consequential object must satisfy each gate to a greater depth. No assurance class ever lowers the invariant floor.

Lifecycle Principles

Beyond the invariants above, the lifecycle is governed by six behavioural rules, each a direct consequence of the Canon.

1. Knowledge always begins as a candidate. Nothing is trusted on entry; status is earned stage by stage. (Principle I.)
2. Every transition requires justification. A gate is a justification checkpoint; an object advances only when it has earned the warrant of its stage. (Principle VIII.)
3. Acceptance is an act of authority, distinct from justification. Justification establishes why an object may be believed; acceptance establishes that an identified authority will rely on it. No object reaches operational use without both. (Principle III.)
4. Governance accompanies every stage. Govern is where legitimacy is maintained, but the Governance Primitives operate from Capture onward. Governance is a property of the whole lifecycle, not a single step within it. (Principles IV and VI.)
5. Knowledge may return to earlier stages as evidence changes. The lifecycle is a loop; returns, refusals and re-justification are normal operations, not exceptions. (Principle X.)
6. Retirement preserves history rather than erasing it. An object leaves active use with its record intact, because trust is a property of transitions over time. (Principle VII.)

Relationship to the Canon

Each lifecycle stage operationalises one or more Canonical Principles: the per-stage Canon basis lines above indicate the principal derivation. The lifecycle as a whole is the method by which the Canon’s central operation — the controlled transition of a knowledge object from one justified state to another — is carried out in practice. The authoritative, complete stage-to-principle mapping is defined in KF-2002 and is not reproduced here, so that a change to the mapping has a single home.

Relationship to the Reference Architecture

Each lifecycle stage is realised through one or more architectural services — for capture, structuring, evaluation, justification, acceptance, governance, versioning and retirement. This document fixes what each stage must achieve and when it may advance; it does not specify the services, stores or technologies that achieve it. That mapping is defined in KF-3000, which a given deployment (KF-4000, and domain instantiations such as a university course domain or a professional-body knowledge domain) then implements. KF-3000 must also enforce the lifecycle invariants as continuous conformance checks, and handle the engineering events as the triggers its services respond to.