KF-2002 · Engineering Practices

Operationalising the Canon through Engineering Practice

Methodology · Draft · v0.1 · 19 min read

Principle (KF-1000)
        ↓
Lifecycle (KF-2001)
        ↓
▸ Engineering Practices (KF-2002)
        ↓
Reference Architecture (KF-3000)
        ↓
Implementation (KF-4000)

Purpose

KF-2001 defines the 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. KF-2002 defines the engineering practices that enable that lifecycle.

A lifecycle answers what happens. An engineering practice answers how that responsibility is discharged. Each practice operationalises one or more Canonical PrinciplesCanonical Principle — an enduring obligation true of any governed knowledge system, admitted only if it survives the two-question test (KF-1000 Part III). Vocabulary → while supporting one or more lifecycle stages, and each is specified as a set of obligations rather than a prescribed procedure. Consistent with KF-2001, this is method, not workflow: a practice fixes what must be true and what must be produced, not the order, tools or cadence by which a given organisation achieves it. Those belong to implementation (KF-4000), and the services that realise these practices belong to architecture (KF-3000). No technology choices are made here.

Relationship to KF-2001

The lifecycle defines engineering states; engineering practices define engineering behaviour. The relationship is many-to-many. Multiple practices may operate within a single lifecycle stage, and a single practice may span several stages. The lifecycle therefore specifies when engineering responsibilities arise; the practices specify how they are fulfilled.

The two documents share one spine. A lifecycle gate is satisfied by executing the practice that supports it; a lifecycle invariant is upheld by the obligations the practices carry; a lifecycle event is what calls a practice into action. Where KF-2001 states that a transition must be attributable, justified and inspectable, it is the practices below that produce the attribution, the justification and the inspectable record. The practices are, in effect, how the lifecycle keeps its promises.

The Engineering Practice Specification

Every practice is specified against the same nine fields, so that practices can be compared, audited and — later — validated uniformly. Immediately below each practice’s title, a single line names the accountable role — the KF-2001 role answerable for the practice’s discharge. Accountability cannot be discharged into a computational substrate, so the answerable role is made visible on every practice rather than left to be inferred.

• Canon principle — the Canonical Principle(s) the practice operationalises.
• Objective — the purpose of the practice.
• Engineering obligation — what must always be true wherever the practice applies (an obligation is invariant-like: it holds at every instant, not only at a gate).
• Supported lifecycle stages — the KF-2001 stages or transitions that depend on the practice, distinguishing the practice’s principal home from the stages it additionally supports.
• Typical activities — the engineering work normally performed.
• Artefacts produced — the mandatory outputs the practice must leave behind.
• Governance checkpoints — how compliance is verified, expressed as checks against gates, invariants and Governance PrimitivesGovernance Primitive — one of the six operations by which warrant is conferred: evidence, authority, provenance, validation, versioning, reversibility (KF-1104). Vocabulary →.
• Success criteria — how success is recognised.
• Failure modes — the characteristic failures when the practice is absent or poorly executed.

On artefacts. Engineering artefact means an inspectable record produced or maintained by a practice as evidence that an obligation has been discharged. An artefact may be represented in several forms, but its required semantic content is fixed by the practice, not by any file, form or database row that carries it. This keeps KF-3000 free to choose representations while remaining bound to the content each artefact must hold.

On success criteria. Success criteria state the required condition. Quantitative thresholds, sampling rules and conformance measures are graded 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 → (KF-2003 · 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 Assurance) and may be further specified by a domain governance profile or implementation, not here — so the criteria below are written to be observable (a reviewer can confirm them) without prematurely fixing metrics or the depth at which each is required.

Practice Domains at a Glance

The four domains follow the arc of the lifecycle: A gives the object identity and form; B earns it justified trust; C governs its acceptance, custody and change; D puts it to use and concludes its life. Together the ten practices provide one principal practice for each of the nine lifecycle stages and the Acceptance transition; several also support neighbouring stages, as the crosswalk records.

Part I · Domain A — Identity & Representation

Purpose: ensure every Operational Knowledge Object possesses a stable identity, explicit structure and inspectable representation.

A1 · Operational Knowledge Object Identification

Accountable role. Contributor. Canon principle. Principle I. Objective. Assign and maintain the identity through which an object is known for its entire life, and bind its origin to it from the first moment. Engineering obligation. Every Operational Knowledge Object has one immutable identity. Editing produces new versions under the same identity; branching, consolidation and supersession create successor relationships — they do not erase, reuse or mutate the identities of the objects involved. Concretely: edits create versions under the same object identity; branching creates new object identities linked to a common predecessor; consolidation creates a new successor identity linked to all source objects; supersession changes status and lineage, not identity. No object exists without a recorded origin. (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 →: single identity; provenance always present. Identity, version and lineage are distinct concerns, separated in KF-3000.) Supported lifecycle stages. Capture (principal home); Structure (support). Typical activities. Intake registration; assignment of a durable identifier; recording of source and origin; disambiguation of a new object from existing ones (is this novel, a new version, a branch, or a consolidation of things already held?); carrying identity forward into structuring. Artefacts produced. An identity record (durable identifier bound to origin, distinct from version and lineage records); a provenance seed that later stages extend. Governance checkpoints. Uniqueness check — the identity resolves to exactly one object and no other object claims it; immutability check — no operation reassigns, reuses or mutates an existing identity; origin-recorded check — the Capture exit gate is met before the object advances. Exercises the Provenance/Traceability primitive. Success criteria. Every object resolves to exactly one identity with a recorded origin; a reviewer can retrieve any object by its identifier and trace it to its source; no two objects share an identifier, and no identifier has been reassigned across the object’s life. Failure modes. Two identities for one object, or one identifier reused for two; identity reassigned or mutated on edit rather than versioned, silently breaking lineage; branching or consolidation that overwrites a predecessor’s identity instead of creating a linked successor; origin unrecorded and later unreconstructable; a candidate admitted with no identifier at all.

A2 · Knowledge Structuring

Accountable role. Knowledge Engineer. Canon principle. Principles I and II. Objective. Transform raw captured material into an inspectable, structured object that downstream stages can reason about. Engineering obligation. The object is inspectable: its structure, semantic type and relationships are explicit and examinable, not implicit in unstructured content — and this holds identically whatever the computational modality of the underlying representation, symbolic or parametric (thereby also discharging Principle V within this practice). (Lifecycle invariant: inspectability, as the Structure exit gate.) Supported lifecycle stages. Structure (principal home). Typical activities. Decomposition into constituent claims; semantic typing; metadata assignment; identification of relationships to other objects; recording of provenance. Artefacts produced. A structured representation; a metadata record; a relationship map; an extended provenance record. Governance checkpoints. Inspectability check — the object can be examined, typed and related; structure-complete check — the Structure exit gate (identity, type, relationships, provenance) is met. Exercises the Provenance/Traceability primitive. Success criteria. A reviewer can identify the object’s type, constituent claims, relationships and provenance without reconstructing them from unstructured source material. Failure modes. Opaque objects that cannot be evaluated or justified downstream; structure left implicit in prose or weights; missing relationships that hide dependency; representations that resist inspection and therefore resist governance.

Part II · Domain B — Evidence & Justification

Purpose: ensure every knowledge object earns justified trust through explicit evaluation and inspectable reasoning.

B1 · Evidence Evaluation

Accountable role. Evaluator. Canon principle. Principle IV. Objective. Assess the quality of a structured object before any question of belief is raised — decide whether it is good enough to be worth justifying. Engineering obligation. No object advances toward justification without a recorded quality verdict and its reasons; evaluation is kept distinct from justification. (Evaluate exit gate; the distinction B1↔︎B2 is load-bearing.) Supported lifecycle stages. Evaluate (principal home). Typical activities. Source assessment; grading of evidence quality; confidence estimation; consistency and completeness checks; recording of a pass, return or reject verdict with reasons. Artefacts produced. A quality-assessment record: the verdict, the criteria applied, and the reasons. Governance checkpoints. Quality-verdict check — the Evaluate exit gate is met and the verdict is recorded and inspectable. Exercises the Validation/Quality primitive. Success criteria. For any object that advanced, a reviewer can retrieve the recorded verdict, the criteria applied and the reasons; objects that were returned or rejected carry the same record and did not proceed. Failure modes. Evaluation conflated with justification (asking why believe it before asking is it worth the effort); low-quality objects passed through; verdicts reached but not recorded; evaluation that advocates for an object rather than assessing it.

B2 · Knowledge Justification

Accountable role. Evaluator, with domain authority where required. Canon principle. Principles IV and VIII. Objective. Establish epistemic legitimacy by attaching an inspectable justification — supporting evidence, counter-evidence, rationale, assumptions and traceability — to the object. Engineering obligation. Every object that will enter operational use carries an inspectable justification, and counter-evidence is recorded as an obligation, not an option. Justification, not truth, is the standard, and it is required even where knowledge resides in parametric form, whose warrant must be reconstructed rather than read off an inference (again holding the obligation across modality, per Principle V). (Justify exit gate; lifecycle invariant: justified transitions; Principle VIII.) Supported lifecycle stages. Justify (principal home). Typical activities. Assembly of supporting and counter-evidence; statement of rationale; explicit statement of assumptions; construction of end-to-end traceability from claim to source. Artefacts produced. A justification record: supporting and counter-evidence, rationale, assumptions, and a traceability chain. Governance checkpoints. Justification-inspectable check — any reviewer can recover why the object may be believed; the Justify exit gate is met. Exercises the Evidence/Justification primitive. Success criteria. An independent reviewer can trace each material claim to its supporting and defeating evidence, recover the stated assumptions, and reproduce the recorded rationale. Failure modes. Advocacy — only confirming evidence recorded; justification that cannot be inspected; truth conflated with justification; assumptions left hidden, so the object’s warrant cannot be tested.

Part III · Domain C — Operational Governance

Purpose: maintain legitimacy, accountability and controlled evolution throughout the operational life of knowledge.

C1 · Knowledge Acceptance

Accountable role. Authority. Canon principle. Principle III. Objective. Have an identified authority certify a justified object as fit to be relied upon, producing the acceptance-state that admits it into operational use. Engineering obligation. No object reaches operational use without acceptance by an identified human authority, and every acceptance is attributable and recorded. Acceptance is distinct from justification: justification establishes why an object may be believed; acceptance establishes that an authority will rely on it. (Acceptance transition; lifecycle invariant: attributable transitions; the human-accountability invariant of the Canon. This practice also exercises the Authority primitive of Principle IV.) Supported lifecycle stages. The Acceptance transition, Justify → Operationalise (principal home). Typical activities. Review of the justification by the authority; decision to accept, provisionally accept or refuse; recording of the acceptance-state, attributed and dated, with the scope of reliance; on refusal, return to Justify or Evaluate with reasons. Artefacts produced. An acceptance record (decision, authority, date, scope); a refusal record with reasons where applicable. Governance checkpoints. Authority-certified check — the object bears an acceptance attributed to a named authority; attribution check — the transition is not anonymous. Exercises the Authority primitive. Success criteria. For any operational object, a reviewer can identify the accepting authority, the date, the scope of reliance and the acceptance-state; refusals carry the authority’s recorded reasons. Failure modes. Acceptance conflated with justification; anonymous or implicit acceptance; acceptance discharged to a machine so that no human is answerable; fluent or plausible output relied upon with no acceptance at all.

C2 · Governance & Stewardship

Accountable role. Steward. Canon principle. Principles IV and VII. Objective. Keep an operational object legitimate as its context changes, through ownership, review, versioning, provenance upkeep and policy compliance. Engineering obligation. Every operational object has an identified steward and a review cycle in force, and its provenance is maintained for as long as it is operational. Governance is continuous, not a one-time step. (Govern standing gate; lifecycle invariant: provenance always present; Principle VII: trust across transitions over time.) Supported lifecycle stages. Govern (principal home); the whole operational life (standing support). Typical activities. Assignment of ownership; scheduling and running of review cycles; approval workflows; version control; provenance maintenance; policy-compliance checks; response to scheduled-review and policy-change events. Artefacts produced. A stewardship assignment; a review schedule and its record; a governance and version log; a policy-compliance record. Governance checkpoints. Ownership-assigned and review-in-force check — the standing Govern gate remains satisfied; provenance-maintained check. Exercises the Versioning/Release and Provenance/Traceability primitives. Success criteria. For any operational object, a reviewer can identify its current steward, its review schedule and last review, its version history and its compliance status; none of these is absent. Failure modes. Ownerless operational knowledge; objects that drift out of review and go stale; provenance decay over time; governance that is recorded at acceptance and then never exercised — legitimacy on paper only.

C3 · Knowledge Evolution

Accountable role. Steward. Canon principle. Principles II and X. Objective. Perform change as a first-class, justified, versioned operation that improves the object while preserving its history and without leaving dependent knowledge silently inconsistent. Engineering obligation. Every change produces a new version under recorded justification and provenance; the prior version is retained; the new version re-earns its warrant by returning through evaluation, justification and acceptance; and the objects that depend on the changed one are identified and dispositioned. (Evolve gate; lifecycle invariants: lineage preserved, justified transitions; the governed-evolution invariant.) Supported lifecycle stages. Evolve (principal home); Evaluate, Justify and the Acceptance transition (support, via re-routing of the new version). Typical activities. Amendment in the light of new evidence; adjudication of competing claims; supersession; branching for divergent contexts; consolidation; impact analysis across dependent objects and actionable forms; routing the new version back to Evaluate/Justify and through re-acceptance. Evolution is called by events — new evidence, a challenge, a scheduled review, an application outcome. Artefacts produced. A new version; a change record (trigger, justification, provenance); lineage links for supersession, branch and merge; a dependency-impact record identifying objects, practices or applications requiring re-evaluation. Governance checkpoints. Change-justified-and-versioned check — the Evolve gate is met; prior-version-retained check; re-acceptance check — the new version passes the Acceptance transition before returning to use; dependency-impact check — affected dependencies have been identified and either revalidated, suspended or routed into Evolution. Exercises the Versioning/Release and Reversibility/Audit primitives. Success criteria. For any change, a reviewer can identify the trigger, the justification, the resulting version, the retained prior version, the affected dependencies and their disposition, and the re-acceptance of the new version before its return to use. Failure modes. Untracked edits; prior versions overwritten; evolution without re-justification or re-acceptance; lineage lost when objects are superseded, branched or merged; a changed object correctly versioned while its dependants are left silently inconsistent.

Part IV · Domain D — Operational Use

Purpose: ensure knowledge creates value while preserving explainability, feedback and historical integrity.

D1 · Operationalisation

Accountable role. Knowledge Engineer. Canon principle. Principles II and III. Objective. Convert an accepted object into an actionable form — the shape in which it can be used in decisions, reasoning or automation. Engineering obligation. The actionable form is traceably linked to the justification and acceptance beneath it; use never detaches from warrant. Only accepted objects are operationalised. (Operationalise exit gate.) Supported lifecycle stages. Operationalise (principal home). Typical activities. Derivation of decision rules, playbooks, patterns, prompts, procedures or models from the accepted object; linkage of each actionable form to the underlying justification and acceptance. Artefacts produced. One or more actionable forms; a linkage record binding each to its justification and acceptance. Governance checkpoints. Form-linked-to-justification check — the Operationalise exit gate is met and every actionable form traces back to warrant. Exercises the Versioning/Release primitive. Success criteria. For any actionable form, a reviewer can trace it to the object version, justification and acceptance-state from which it derives. Failure modes. Actionable forms severed from their justification — ungoverned knowledge in use; operationalisation of objects that were never accepted; forms that cannot be traced back to a source object.

D2 · Knowledge Application

Accountable role. User, under Steward oversight. Canon principle. Principle IX. Objective. Use governed knowledge in practice while preserving explainability, and capture the outcomes of use as new evidence. Engineering obligation. Knowledge remains explainable in use whatever the modality in which it resides, and the outcomes of application are captured and attached to the object. Application uses the object without transforming it; the object remains Governed. (Apply exit gate; Principle IX; explainability is owed by the system, not the substrate — and is therefore preserved across modality, per Principle V.) Supported lifecycle stages. Apply (principal home); Evolve and Retire (support, which application’s outcome events call). Typical activities. Use in human decisions, AI reasoning, automation and organisational workflows; use in teaching and advisory work; capture of outcomes; raising of feedback events that call Evolution or Retirement. Artefacts produced. An outcome record attached to the object, feeding the Evidence dimension and the evolution/retirement decision. Governance checkpoints. Explainability-in-use check — an account of how the knowledge produced a given result can be given, regardless of substrate; outcome-captured check — the Apply exit gate is met. Exercises the Reversibility/Audit primitive. Success criteria. For every material application outcome, the system can identify the object version used, its actionable form, the governing acceptance-state and the recorded path from input to result. Failure modes. Black-box application that cannot be accounted for; outcomes not captured, breaking the feedback loop; application of ungoverned or unaccepted objects; use that has quietly detached from the justification it was meant to carry.

D3 · Knowledge Retirement

Accountable role. Steward or designated Authority. Canon principle. Principles VII and X. Objective. Conclude the operational life of an object without destroying its lineage, recording why it is no longer active. Engineering obligation. Retirement is a change of state, not a deletion; lineage is preserved; the reason is recorded; and retirement is reversible in principle. History is append-only. (Retire gate; lifecycle invariant: lineage preserved; Principle VII.) Supported lifecycle stages. Retire (principal home). Typical activities. Determination of the retirement reason (obsolete, superseded, merged, archived, withdrawn); transition of the object to the historical state; recording of the reason; preservation of the full record; provision for reactivation through Evolution should evidence change. Artefacts produced. A retirement record (reason, date, authority); the preserved historical object with its lineage intact. Governance checkpoints. Reason-recorded and history-preserved check — the Retire gate is met; lineage-intact check — no history is erased and superseding links remain traceable. Exercises the Reversibility/Audit primitive. Success criteria. For any retired object, a reviewer can identify the retirement reason, date and authority, retrieve its full historical record and lineage, and determine the successor object where one exists. Failure modes. Deletion that destroys lineage; retirement with no recorded reason; silent removal; a superseding object that breaks the link back to the object it replaced.

Crosswalk

Each practice maps to the Canonical Principle(s) it operationalises, the role accountable for it, its principal lifecycle home, and the stages it additionally supports.

Constitutional coverage. The crosswalk’s Canon column records each practice’s principal principle. Because two principles are cross-cutting rather than stage-bound, coverage of all ten is stated explicitly here:

• Principle I — A1, A2 (the object, and its inspectable representation)
• Principle II — A2, C3, D1 (engineering as a lifecycle)
• Principle III — C1, D1, D2 (collective authorisation and accountable use)
• Principle IV — B1, B2, C1, C2 (governance as constitutive; the six primitives)
• Principle V — A2, B2, D2 (the obligation preserved across every computational modality)
• Principle VI — the methodology as a whole: the lifecycle (KF-2001) and these practices coordinate engineering, capability and governance on a single object; no one practice owns it, and the crosswalk itself is its evidence
• Principle VII — C2, D3 (trust preserved across transitions over time)
• Principle VIII — B2 (inspectable justification for every transition)
• Principle IX — D2 (explainability in use, across modalities)
• Principle X — C3, D3 (designed for governed evolution)

The crosswalk records each practice’s principal Canon basis and principal lifecycle home. Additional stages, principles and Governance Primitives exercised by the practice are stated in its specification. Read down the principal-home column, the ten practices provide one primary practice for each of the nine lifecycle stages and the Acceptance transition. Read across the Canon column, every Canonical Principle must be discharged either through a principal mapping or an explicitly identified secondary obligation. Together, these two tests establish lifecycle coverage and constitutional coverage without assuming a permanent one-to-one correspondence between principles, stages and practices.

Relationship to KF-3000

The practices defined here specify engineering responsibilities — what must be done, what must be produced, and how compliance is verified. KF-3000 defines the architectural services that realise those responsibilities, and must in particular provide the services that produce each practice’s mandatory artefacts and that enforce its governance checkpoints as continuous conformance checks. Because this document keeps identity, version and lineage distinct, and states each artefact by its required semantic content rather than its form, KF-3000 can justify each service by the practice obligation it fulfils, the artefact it maintains and the checkpoint it enforces — rather than inventing components one by one. No technology choices are made in this document; the practices are stated so that many architectures could satisfy them, and so that any that claims to must be measurable against the success criteria and failure modes recorded above.