DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path investigations/loomworks-okf-use-case-legacy-estate-v0_1.md

Loomworks — Open Knowledge Format Use Case: The Legacy Estate — v0.1

Document type: Use Case (companion to the comparison investigation v0.1 and the restatement use case v0.1) Version: v0.1 Date: 2026-06-13 Operator: Marvin Percival


Plain-language summary

What this document does. It works a second difficult knowledge-management problem — a vast legacy software estate — through the same boundary as the restatement use case, but it pulls on a different part of Loomworks. The restatement case was about knowledge changing under consequence. This is about knowledge that is uncertain, decaying, contested, and partly lost, where the danger is false confidence at scale. It is a companion to the comparison investigation v0.1 and the restatement use case v0.1.

The scenario. Meridian Bank uses the Open Knowledge Format to capture its legacy estate. The reference enrichment agent crawls decades of code and emits a confident concept file for every job and module. Capture is cheap — and the same files now make a model's inference, a retiring engineer's recollection, and a possibly-wrong 1987 design note all look equally authoritative. An autonomous refactoring agent is poised to act on them.

What it shows. The instrument that meets this is the one the restatement case barely used: the inward-inference provenance thread and the tie-to-source trust axis. Here it is the whole game. The legacy estate is the cleaner demonstration of the trust-and-provenance layer the format declines.

Carries a correction. This document records a correction to the restatement use case v0.1 regarding how a changed premise propagates across systems. See section 06.

Scope. Illustrative. Fictional institution. No code, no specification change, no seed amendment proposed.


01 — The setting

Forty years of core systems, and the cheapest map anyone has ever offered to draw.

Meridian's core ledger, settlement, and overnight batch systems were written across four decades. The knowledge of how they work lives where the Open Knowledge Format's own announcement says enterprise knowledge lives: in code comments, in runbooks, and in the heads of a few senior engineers. There has never been a usable, current map of the estate. Every modernisation attempt has stalled on the same wall — no one fully understands what the systems do, and the people who came closest are leaving.

So the bank reaches for the format. The reference enrichment agent walks the codebase, drafts a concept document for every batch job, copybook, and module, then makes a second language-model pass that reads what documentation exists and fills in a description, the apparent inputs and outputs, and the apparent dependencies. In weeks, Meridian has its first catalogue of the estate. For an organisation that has never had one, this is a real and welcome thing, and Loomworks does not take it away.

02 — Where the cheap capture turns dangerous

Almost nothing in a legacy estate is authored knowledge. It is archaeology — and the format writes archaeology as if it were fact.

The description of a 1987 settlement job in Meridian's new catalogue did not come from someone who knows what the job does. It was reconstructed — inferred by a model reading the code, recalled by an engineer two years from retirement, or copied from a design document that may have been wrong the day it was written. Three very different kinds of claim. The format writes all three the same way: a concept file with a type field and a confident paragraph of prose.


---
type: Batch Job
title: STLMT_NIGHTLY_B
description: Reconciles intraday settlement positions and posts
  net movements to the general ledger before the 02:00 cutoff.
tags: [settlement, batch, ledger]
timestamp: 2026-06-02T11:14:00Z
---

# Behaviour
Reads [POSN_INTRADAY](/tables/posn_intraday.md), writes [GL_POST](/tables/gl_post.md).
Must run before [GL_CLOSE](/jobs/gl_close.md).

Nothing in that file records that the entire description is an unconfirmed inference by a language model, or that the ordering constraint came from one engineer's memory and has never been checked against what the job actually does. The file looks identical to one a person verified against production. The enrichment agent has laundered inference and tribal recollection into something that reads as authoritative. Then the next step — an autonomous refactoring agent told to modernise the batch tier — acts on a confidently-wrong inferred concept and breaks a system nobody fully understands. The cheapness of the capture is the trap, not the gift.

03 — The difficult problem, stated plainly

The hard part is not capturing the knowledge. It is knowing how much to trust each piece, and not acting past that.

> Meridian wants to modernise the estate with help from agents. To do that safely it has to answer questions its new catalogue cannot: which of these descriptions is verified and which is a guess; what do we believe only because one person said so, and that person retires in March; what in here has never once been confirmed against running behaviour; and where two sources flatly disagree, which is right.

Four demands sit inside that, and none is about volume — the format handles volume well. They are all about trust under uncertainty:

04 — What the format can and cannot do

It captures everything and grades nothing.

What it can do

What it cannot do, by design

The format's minimalism, harmless when knowledge is stable and confirmed, is actively hazardous when knowledge is mostly unconfirmed and an agent is about to act on it. It will tell an autonomous agent that an unverified guess and a production-confirmed fact deserve equal confidence, because to the format they are the same file.

05 — The same estate, run through Loomworks

Here the provenance thread is not a feature among others. It is the whole instrument.

Room one — Memory · the inward-inference thread and tie-to-source trust. Each system's catalogue enters as its own engagement. As concepts become assertions in Memory, the trust axis is not human-versus-machine — it is tie-to-source. The settlement job's description enters as the grade of claim it actually is: inferred-from-code-reading carries an inward-inference thread and is marked machine-origin in a way that cannot be suppressed; recalled-by-a-named-engineer ties outward to that person; asserted-by-a-1987-design-document ties to the document; confirmed-against-production-behaviour ties to the observation that confirmed it. The confidently-wrong inference is now visibly an inference. An agent reading the estate sees the difference the format erased.

Room two — Manifestation · the recall queries a legacy bank needs. Because every assertion is tied to its source, Manifestation can answer the questions section 03 named. What do we believe only because one engineer said so? — surface every assertion whose sole outward thread is that person, the set that becomes unsourced when they retire. What has never been confirmed against running behaviour? — surface every assertion lacking a production-confirmation thread, the set an autonomous agent must not act on. These are not reports someone compiles by hand over a year; they fall out of recall over knowledge that carries its provenance.

Room one — Memory · contested knowledge, held faithfully. Two engineers disagree about what the job does; the runbook says a third thing; production behaviour suggests a fourth. Loomworks holds all four as distinct assertions with distinct provenance and makes the conflict visible. It does not require the Operator to resolve it in order to record it. In an estate where much of the truth is genuinely unknown, recording the disagreement faithfully is the correct behaviour, and forcing a premature resolution is the failure mode to avoid.

Room three — Shaping · composition across systems is deliberate, not automatic. The estate is not one body of knowledge — it is a federation of engagements, one per system, and the cross-system dependencies are exactly what the bank has lost track of. Per the seed, references between engagements are non-transitive by default, and composition across scopes lives in Shaping, not Manifestation. So an apparent dependency between the settlement engagement and the ledger engagement does not silently propagate; the Operator composes the cross-system view deliberately in Shaping. This is the right discipline for legacy work: a silently-assumed cross-system link is how the estate became incomprehensible in the first place.

Governance as grading, with reach and an anchor. In the restatement case the gate withheld settlement until a human confirmed a knowable fact. Here, certainty is often permanently unreachable — the authors are gone and the only witness is the code. So governance takes a different shape: the Operator grades what is safe to act on at what confidence and authorises agents accordingly. OVA carries that authorisation reach — a refactoring agent permitted to touch the reporting subsystem but not the core ledger, and never permitted to act on an assertion still marked inference-only. FORAY anchors the attestations that matter most: this understanding of system X was validated against production on this date — the evidence an operational-resilience regulator will ask for.

06 — What this shows, and a correction to the restatement use case

This estate is the cleaner demonstration of the layer the format declines.

The restatement use case showed correction — knowledge changing under consequence, with the trajectory preserved. This shows graded, contested, decaying knowledge that must not be acted on as if it were certain. That is the part of regulated knowledge management the Open Knowledge Format most explicitly declines, and the part its cheap, confident capture makes most dangerous at scale. The format gets Meridian its first map of the estate, and Loomworks is the layer that records how much each line of that map can be trusted, surfaces what rests on a fading source, holds the disagreements, and refuses to let an agent act past the confidence the knowledge actually carries.

Correction · restatement use case v0.1, section 05

Prior phrasing. The restatement document said, loosely, that changing one assertion makes "the whole dependent set light up," implying automatic propagation across the affected knowledge.

Corrected position. That holds within a single engagement's Memory. Across engagements it does not: references between engagements are non-transitive by default, and composition across scopes lives in Shaping, not Manifestation. So a cross-system or cross-engagement dependency does not auto-propagate — it must be deliberately composed by the Operator in Shaping. The restatement case happened to sit largely within one engagement, which is why the looser phrasing passed; this legacy case, a federation of engagements, makes the distinction load-bearing. The prior phrasing is preserved here rather than silently rewritten.

Whether to amend the restatement document itself to v0.2 to carry this correction inline is an Operator decision, recorded here and not taken.


Note