Reconstructing the Continuum
From preserved sequence, through institutional reframing, to an instrument capable of holding the whole record
Michael J. Burdette-Deakin - 15 October 2026
1. Preserving the sequence: 10 October 2022
The earliest source in the construction lineage is not a software build. It is a skeleton chronology written in OpenOffice and saved at 21:40 on 10 October 2022. It contains twenty-four dated entries followed by two numbered scope statements. The entries preserve a sequence running from October 2017 to July 2022 and identify exhibits, crime references, civil proceedings, police referrals, mental-health intervention and recurring allegations.
The chronology was completed immediately before mental-health self-referral and the loss of effective verbal and executive function recorded later that evening. Its purpose at that moment was preservation: it externalised the minimum viable sequence before its author could no longer communicate that sequence coherently. The final two statements expressly identify a recurring pattern and warn that the document is only a skeleton rather than an exhaustive account.
This file is therefore the primary source record for the later reconstruction, but it is not designated as Stage One. It predates the formal construction programme by more than two and a half years.
Primary evidence: Chronology.rtf; Windows filesystem timestamp 10/10/2022 21:40. The document itself carries zeroed internal timestamps, no author metadata and no revision count.
2. Recovering the displaced provenance: May 2025
Formal reconstruction began in May 2025 by returning to the preserved 2022 chronology. The initial problem was no longer simply to list events. It was to recover the provenance that had been displaced by an accumulated institutional frame and to test how the originating allegations, later records and downstream consequences related to one another.
A flat chronology could preserve order, but it could not adequately hold the growing structure. One event could be represented differently in several institutional records; a later disclosure could alter the interpretation of an earlier event; one allegation could travel through housing, police, court and healthcare systems; and the source of a proposition had to remain distinguishable from its later repetition. The reconstruction consequently required explicit source descent, cross-reference, contradiction retention and movement between non-adjacent dates.
Corpus context: the life ledger
The reconstruction corpus did not begin as a litigation bundle. It was a personal life ledger containing material created from at least 1999 onward: correspondence, online activity, offline coding, records, working files and later institutional documents. By May 2025 the archive contained approximately 54,000 files. Roughly half were PDFs, including aggregated bundles containing very large numbers of constituent documents.
Between 2017 and 2022, while personal agency and cognitive stability were being progressively eroded, critical paper records were nevertheless scanned into the computer. Some material had already arrived electronically as PDF. Exhaustion and disturbance made complete scanning impossible. The first committal bundle is the only complete bundle no longer held locally, although several critical pages survive in PDF and a complete copy should remain with Birketts.
The initial retrieval advantage was autobiographical memory. A filename would often recall when the file had been created and approximately what it contained. That memory provided a rough human index into the archive, but the task remained enormous: tens of thousands of heterogeneous files, nested documentary bundles and incomplete paper-to-digital capture had to be searched, associated with events and placed back into temporal order.
Approximately 2,000 files were scraped from the larger life-ledger archive because each was relevant in some way to the continuum under reconstruction. They formed a candidate evidence set, not the instrument corpus itself. From that set, approximately 400 files were selected into what now constitutes the larger part of the current corpus. Selection began with the document sets needed to support the twenty-four dated entries preserved in the 2022 RTF and continued as reconstruction exposed earlier sources, later consequences, contradictory records and further documentary dependencies.
Some relevant documents remain unlocated despite continuing searches. They are important to the fuller account but are not essential to the continuity already established by the retained corpus. Their absence is therefore recorded as an incompleteness in documentary recovery, not as a break in the reconstructed sequence.
The later instrument progressively externalised both parts of the original human task: remembering where material was likely to be found and preserving why each selected file mattered to the developing temporal account.
3. First reconstruction: turning memory back into record
The build-log register designates the Whiteboard Report as Stage One and describes it as the initial static narrative later replaced by successive interactive HTML architectures. Its document metadata records creation on 6 June 2025, modification on 8 June 2025 and seventeen revisions.
Stage One converted the emergency skeleton into a substantially wider reconstruction. It added an executive account, contextual history, a detailed chronology, linked-evidence paths, legal and institutional analysis, and explicit treatment of cumulative impact. The report already attempted to show interconnectedness rather than merely enumerate incidents, but it remained a serial document whose relationships had to be expressed through prose and repeated cross-reference.
The associated expanded Chronology document was created on 10 June 2025, last modified on 13 June 2025 and reached revision sixteen. Its structure included an executive summary, a register of individuals and entities, a detailed chronology, legal ramifications, cumulative impact and appendices covering institutional conduct, narrative conflict, police records and supporting analysis.
These files establish the first construction stage: the record had moved beyond emergency preservation into deliberate forensic reconstruction, but its operating surface was still a conventional rich-text document. The scale and relational density exposed during this stage supplied the reason for the subsequent move into vanilla HTML, JavaScript and CSS.
Stage evidence: Whiteboard Report.docx; Chronology.docx; and the Stage One designation in build-logs.html.
4. Making the record traversable
Stage Two begins with recognition of a practical review problem. Supplying a large paper corpus would impose substantial printing and handling costs while requiring a legal professional to spend expensive cognitive time repeatedly searching for the document associated with each proposition. The first engineering response was therefore direct: move the reconstruction into vanilla HTML, JavaScript and CSS and link the supporting documents from the point at which they became relevant.
The final Stage Two construction consists of an Indexed Interactive Chronology and a separate Appendices surface. Together they contain approximately 260 KB of authored HTML, styling and executable browser logic. The chronology carries 134 direct paths into the Linked Evidence corpus alongside approximately fifty fragment-bearing interface and cross-reference routes. Evidence retrieval consequently becomes an authored route rather than a manual paper-search task.
The chronology introduces a two-pane operating interface. A persistent index in the left pane opens selected sections as working tabs in the right pane. Tabs can be activated, closed, printed individually or reduced to the current focus. The chronology tab generates its jump menu by walking the authored chronology in the DOM, assigning usable destinations and exposing nested entries and linked evidence without requiring a second jump list to be maintained manually.
The companion Appendices file separates extended analysis from the principal temporal sequence. It provides fifteen appendix destinations and generates its own appendix-selection menu at runtime. Chronology entries can therefore descend into source documents, move laterally into analytical appendices and return to the temporal account without forcing all material into one continuous document.
This is the first recognisable software instrument in the lineage. The browser is no longer merely displaying a converted report: JavaScript constructs navigation from the authored structure and manages the reader's working state. Its remaining constraint is singularity. Content, presentation, evidence paths and runtime behaviour are still embedded together inside two large files, and the architecture assumes one chronology, one appendices collection and one corpus location.
Stage evidence: Indexed Interactive Chronology Complete.html; Appendices.html; and the Stage Two designation “Indexed Interactive Chronology + Appendices” in build-logs.html.
5. The apparent recovery and the institutional turn
Once Stage Two had stabilised, it stood as the working Exemplar. Its linked chronology made the evidence reachable. At the same time, HNK possessed the inherited case material, pursued the distinct unlawful-arrest claim and confirmed its settlement. From the author’s position, those developments reasonably appeared to mean that ground was being regained: material had survived, professional representatives had it, one wrong had produced a result, and the wider provenance was being placed before people capable of acting upon it.
The later record shows the opposite movement. HNK’s engagement exposed a failure mode more consequential than missing evidence: a professional reviewer could possess the documents and still prevent them from operating as a continuum by substituting a simpler classification and narrowing the scope around it.
The current graph fixes the sequence. HMP Norwich had already recorded that the imprisonment arose from a civil offence and that criminal Home Detention Curfew eligibility did not apply. HNK later received the inherited case material, pursued the distinct 27 September 2020 unlawful-arrest claim and confirmed its settlement on 2 June 2025. The County Court committal of 13 October 2022 remained a civil process with a separate provenance.
Michelle McMahon’s email of 11 June 2025 performs the decisive reframing in two moves. It first substitutes “conviction” for the civil committal: “overturning a conviction”. It then lets that substituted category dictate jurisdiction: overturning it is said to be “a criminal matter” requiring a criminal solicitor. The conclusion therefore does not follow from the originating process; it follows from the new label introduced in the email.
The same email partitions the continuum around that substitution. The Whitebook reconstruction is reduced to helpful “background”; HNK’s attention is narrowed to the actions of the arresting officers and the legal tests for false arrest and imprisonment; claims against landlords or their agents are excluded; a further internal review or input from Vivien is declared unnecessary; and newly supplied material is acknowledged for attachment to the files without being integrated into the analysis. HNK could consequently retain six discrete actions-against-the-police claims while placing the civil foundation, the originating landlord conduct and the committal produced downstream of them outside the professional frame.
This was not an absence-of-document problem, nor simply confusion caused by the fact of imprisonment. It was classification substitution followed by scope partition. The settlement on 2 June 2025 appeared to widen the interpretive aperture: it separated the concluded police tort from the civil committal chain and made the larger continuum more legible. McMahon’s reframing did the reverse. It treated the settled arrest as a bounded claim, renamed the civil committal as a criminal conviction, and thereby preserved the inherited fragments instead of testing their common provenance. HNK’s final response of 17 July maintained that limited strategy, and the substituted classification was subsequently carried into the Legal Ombudsman process during 2026 rather than tested against the originating court record.
This is where the continuum first visibly turns within the professional machinery. The originating events predate HNK, but this is the point at which apparent recovery becomes renewed containment. The record is not rejected wholesale. It is accepted in fragments, reclassified at the controlling junction, and then distributed into scopes too narrow to test the common source. That distinction explains why the turn was not immediately visible from inside the process.
The reconstructive response was Stage Three: expansion of the two-file instrument into a portable compilation of coordinated HTML surfaces under a common Index Hub. The supplied final construction comprises ten principal files and approximately 772 KB of authored HTML, CSS and JavaScript: Chronology, Chronology Search, Claims Matrix, Evidence Matrix, Appendices, Legal Breaches, GP Records, Hospital Records, NHS Healthcare and the Index Hub.
The compilation provides two deliberate directions of travel. A reviewer can work bottom-up from dated chronology entries into records and source documents, or top-down from asserted heads of claim through an evidence matrix into the chronology nodes and material relied upon. Medical-record surfaces preserve their own sequences while remaining connected to the wider continuum. Search, generated jump menus, claim anchors, appendix destinations and a persistent navigation scheme reduce the opportunity to treat one institutional fragment as the whole case.
The architectural gain is therefore not just additional subject matter. Stage Three begins to encode resistance to jurisdictional fragmentation. Chronology, claims, evidence, medical records and extended analysis remain separately inspectable but are held inside one navigational compilation. Its remaining limitation is duplication and tight physical coupling: each surface still carries substantial embedded content, styling and script, and consistency across the compilation still depends heavily on manual editing.
Stage evidence: Index Hub.html; Chronology.html; ChronologySearch.html; Claims Matrix.html; Evidence Matrix.html; Appendices.html; Legal Breaches.html; GP Records.html; Hospital Records.html; NHS Healthcare.html; the graph sequence from 2023 to 2026; and the Stage Three designation “Single Navigation Bar Compilation” in build-logs.html.
6. Enlarging the stage as the institutional theatre expands
The continuum did not remain within the boundaries for which Stage Three had been built. As additional institutions, records and oversight processes entered the theatre, each new domain required both space of its own and a way to remain connected to the same underlying sequence. At the same time, the author experienced the responses of the IOPC and Norfolk Professional Standards Department as procedural circling around the expanding problem rather than intervention in it. The immediate response was to enlarge the stage again.
Stage Four wrapped the existing compilation inside a new Chamber architecture. Its root page describes a structure that had changed, by 30 October 2025, from an anticipated two-tier system into a three-tier problem. The proposed upper level was the “Defect”; Tier One concentrated on setting aside the 13 October 2022 judgment; Tier Two addressed actions against State and institutional actors; and an Orientation and Analytical Suite attempted to explain provenance, methodology, legislation, records and the compilation itself. The earlier chronology, appendices, matrices and medical-record surfaces remained underneath this new superstructure.
The construction shows the pressure of rapid conceptual expansion. Several parallel shells—Core Index.html, Meta Index.html, tier-one.html, tier two.html and specialist viewers—repeat a wide graphical navigation ribbon as bitmap image maps with hard-coded coordinates. Targets move between whole-page shells, named iframes and fragment-like shell routes. Filename, case and path variants appear across those routes, while planned surfaces and earlier names coexist with their replacements. The supplied archive is therefore a transitional construction rather than a stable release.
Its productive idea was the hero map. The wide diagram did more than inventory the available pages: it tried to show a route out of the evidential mass. Claims, evidence, legislation, the set-aside litigation arc, chronology, appendices, probative content, advocate or peer access, proposal, search, orientation and the separate record domains were drawn as one connected terrain. Variant map images then highlighted the route appropriate to the reader’s present position—for example, the green path running from the set-aside litigation arc through the central system, or the route into Orientation. Navigation was being conceived as movement through a problem, not merely selection from a menu.
The experiment was quickly abandoned before that idea had coalesced. The map was a manually drawn and manually wired hypothesis: its routes were encoded through separate bitmap variants, fixed image-map coordinates, parallel shells and changing iframe targets. It could illustrate a route already imagined, but it did not yet possess a stable semantic model from which routes could be derived. More domains therefore meant more map variants, more pages and more coordination burden.
Stage Four’s actual contribution was consequently narrower and more important than a premature multi-view architecture. It posed the representational question: how can a reader trace a defensible route through a continuum that will not stop expanding? Abandoning the Chamber did not answer that question. It carried the question into Stage Five, which developed into the baseline for the present system. Node taxonomy and CHIP/ID were later born at the end of the Stage Five lifecycle; they must not be projected backwards into Stage Four.
Stage evidence: the supplied stage-four.zip, containing the root index.html, the Chamber shell family, the base hero map and its route-highlighted graphical variants, and the retained Stage Three compilation. Archive modification dates concentrate the experiment between 28 October and 1 November 2025. This stage is recorded as an abandoned but causally important construction.
7. Consolidating the reconstructed terrain
Stage Five is the first clear progression beyond the multi-shelled Chamber. The hero map’s attempt to describe a route through the material is replaced by a predominantly single-shell tab system. One html/index.html surface owns the working environment. Its ribbon opens four contextual groups—Epistemology, Provenance, Orientation and Probative—and ordinary internal links are intercepted by js/core.js and opened as working tabs inside that shell.
The tab runtime normalises a document path into a stable tab identity, creates one iframe pane for that document, reuses the pane when another anchor in the same document is requested, and scrolls to the requested destination after loading. Shell hashes use a document~anchor form to open a particular internal surface at a particular point. Tabs can be activated, closed or reduced to the present focus. The chronology remains deliberately exceptional: the shell labels it as opening in a browser tab, preserving a large sovereign temporal surface while the surrounding material is gathered into the common workspace.
This was also the principal chronology-fleshing stage. The supplied checkpoint’s chronology.html is approximately 195 KB and runs from 2000 through 2025, carrying hundreds of evidence references and increasingly dense lateral links into appendices, CAD, custody, crime, healthcare, HNK and oversight material. A similarly large search surface reproduces the yearly material for retrieval. The record was becoming sufficiently populated for recurrence to be seen across domains rather than inferred from a few selected incidents.
The representational vocabulary remained preliminary. The chronology explicitly identifies only a keystone pivot (◆) and a recycling note (⤤), alongside visual evidence classes for custody, crime, CAD and dates. There is no implemented CHIP grammar, seed system or developed node-marker taxonomy in this checkpoint. Those ideas were beginning to coalesce during the Stage Five lifecycle—“cooking” as a way to compress recurring meaning and route relationships—but they would not be implemented for another five months.
Stage Five therefore matters as the baseline rather than the completion of the later graph. It consolidated navigation, gave the chronology room to accumulate evidential density, and established repeatable document-and-anchor addressing. Only after that substrate had been operated against the growing continuum could node taxonomy and CHIP/ID become explicit machinery rather than an imposed speculative scheme.
The archive dated 13 May 2026 fixes the other end of that incubation period. By then the idea had become an authored and executable system: a 23-marker taxonomy across six categories; six CHIP/ID domains; numbered classes; a seed registry; compact data-chains declarations on backward chronology jumps; runtime parsing and chip rendering; a CHIP matrix; and graph projections that consumed the same relations. The dated transition is therefore visible in the artefacts themselves: absent from the December Stage Five checkpoint, fully operational in the May build.
Stage evidence: 13-12-2025-stage-five.zip; html/index.html; js/core.js; html/chronology.html; html/search.html; and the included manifest for “04-12-2025-Stable-Release-v5”, recording 467 files across 48 folders in the complete release corpus.
8. Converting recurrence into executable relation
The build dated 13 May 2026 stands approximately one year after reconstruction began in May 2025. It is the sixth major construction stage and the final stage before development turned towards a multiplex system. It was not yet a multiplex platform and it was not yet a general-purpose authoring system. It was an extensively developed single-graph instrument in which the chronology, its data pipeline, its relational grammar and its analytical projections had become an operating whole.
Authoring had nevertheless begun to appear as a separate possibility. A basic template author could produce two forms of chronology node:
- single entry — one event attached to one date;
- compound entry — several events or records grouped under one date.
Three additional authors were under construction in parallel. They had not yet become a unified authoring environment or even a settled architecture. Authoring remained a loose but increasingly persistent idea: if the working Exemplar could be decomposed into reproducible operations, another graph might eventually be built without repeating its year of hand construction. The authoring line and the publication Exemplar were therefore related but distinct: one was beginning to formalise production; the other was the live instrument whose structure had grown out of the reconstruction itself.
The distinction between conception and implementation matters here. During Stage Five, recurring pivots, evidence classes and cross-links supplied the observational substrate from which taxonomy and CHIP/ID could be imagined. They were not yet an implemented grammar in the December checkpoint. During late April and May, that latent model became explicit data and runtime behaviour.
The attached May build proves implementation rather than aspiration. html/chrono-core/data/tri-axial-data.js identifies itself as seed-authoring-export version 1.2 and records a save time of 13 May 2026, 12:01:58Z. Its registry defines seed actors and its entries associate dates with domains and kernel seeds. The chronology data contains hundreds of data-chains declarations, while chrono-core.js parses those declarations and renderChips() renders domain, class and seed. The chronology and search surfaces expose both the marker taxonomy and CHIP/ID guide, and the 3D graph provides CHIP-matrix and chain-trace views. By 13 May, both systems were operational components.
Stage Six is therefore the completed pre-multiplex baseline. It demonstrates what one graph could do after a year of corpus reconstruction and iterative interface building. The next problem was no longer how to enlarge that single graph. It was how to separate graph-owned content, reusable interpretation, rendering machinery and authoring operations sufficiently for the same system to construct and operate more than one graph.
Stage evidence: 13-05-2026-Current-Stable-Build.zip; html/chronology.html; html/chrono-core/data/chronology-backup.js; html/chrono-core/data/tri-axial-data.js; html/chrono-core/js/chrono-core.js; html/chrono-core/js/chrono-jump-builder.js; html/3d-graph.html; and the early authoring tools described in the original development record.
9. Engineering ledger: capacity acquired during reconstruction
| Checkpoint | Observed architecture | Capability gained or stabilised | Constraint still visible |
|---|---|---|---|
| 4 April 2026 Publication v5.4.3 |
Single graph; chronology and much of its data embedded in html/chronology.html. Shell, document viewer, search, claims, appendices and record surfaces already present. |
Operational forensic reconstruction; internal jumps, evidence links, recurring pivots and companion analytical surfaces. Basic two-form chronology-node template author existed alongside three additional authors under construction. The corpus supplied the substrate from which the later grammar was being inferred. | Graph identity was implicit. Content, interpretation and rendering remained tightly coupled. The publication could assume one corpus, one chronology and singular runtime ownership. |
| 13 May 2026 Current stable build checkpoint |
Chronology reduced to a reusable renderer. Data moved into chrono-core/data/*-backup.js crates. chronology-backup.js, tri-axial-data.js and dedicated chronology core files were present. |
Node-marker taxonomy and CHIP/ID were now implemented: authored seed registry and domain assignments, hundreds of backward-jump chain declarations, runtime chip rendering, CHIP matrix and 3D graph projections. Runtime construction through localStorage also separated chronology, appendices, claims, CAD and healthcare records from their renderers. |
Crate locations and storage keys were still fixed to one graph. Separation of data from renderer had been achieved, but ownership remained singular. |
| 6 August 2026 Current stable build |
Single-graph runtime with annexe.html; semantic chronology; taxonomy/grammar profile and runtime; authoring and state-user guide layers; consolidated 3D graph. |
Taxonomy and CHIP/ID interpretation became explicit machine-readable grammar rather than only embedded presentation. Semantic extraction and profile-driven rendering emerged. The Annexe began separating the chronology from its peripheral working surfaces. | The profile was becoming swappable, but the surrounding runtime still assumed a single graph and fixed companion datasets. |
| 8 September 2026 System checkpoint |
First evidenced merger of the single-graph Exemplar with multiplex architecture. Registry, graph manager, shell-profile runtime and graph-scoped context/routing appeared under the transitional case-* vocabulary. |
Multiple graphs could be declared and selected. Chronology, Annexe and shell navigation began carrying graph identity. Graph-specific ribbons and runtime separation became architectural requirements rather than optional conventions. | The merger was transitional. Some single-graph assumptions survived inside routes, window names, resource paths and storage contracts. case-* also implied a use class that the instrument no longer needed. |
| 30 September 2026 Stable multiplex |
Graph-owned material moved under archive/file-*/. Registry entries declared graph identity and directories. Shared renderers used file-context.js, file-route.js, graph-scoped keys and graph-specific ribbon profiles. |
The instrument became directory-driven and graph-agnostic. The same chronology, semantic, relational, synthesis, Annexe and record machinery could interpret graph-owned crates selected at runtime. The neutral file-* vocabulary replaced the case-specific abstraction. |
Multiplexing exposed inherited assumptions that had been harmless in the single-graph system: hard-coded paths, unscoped companion windows and readers that consumed fragments without first establishing graph context. |
| 10 October 2026 Current repaired revision |
Registry and directory scope remain authoritative. Internally stored and externally linked graph instances use the same renderer contracts. External directory access is brokered at runtime without copying the corpus into the instrument. | Dispatch routing, document routing, named-window isolation, graph-scoped runtime keys and linked-directory mounting have been repaired and checked across two registered graphs. The common entry remains the graph registry even when only one graph is registered; the former single-graph shell behaviour has been phased out. | A second full corpus does not exist. The smaller Hampshire graph is a separation fixture, not a semantic duplicate of GO1NR161. Full-corpus parity testing would require construction work disproportionate to the routing question. |
10. The reconstruction determines the machinery
The April position matters because it prevents a false account in which multiplexing created the instrument. It did not. The analytical method, document descent, chronology navigation and observational basis for the later grammar existed before multiplexing. Taxonomy and CHIP/ID were then made executable during the April–May transition, still months before multiplex ownership appeared.
The April chronology was a large, self-contained artefact. That made the relationship between node, evidence and interpretation easy to operate, but difficult to reuse. Its singularity was productive during discovery: semantics could be stabilised before the system was required to abstract them. The early author likewise concentrated on the smallest valid authored unit—one dated node or a compound dated node—rather than attempting to design the eventual platform in advance.
This order is significant. The authoring grammar was extracted from a working corpus; the corpus was not forced into a speculative schema designed without it.
Archive evidence: the earlier html/chronology.html; build-logs/tools/chronology-templates.html; and the embedded “Creation of initial chronology markup template” development record. The marker-taxonomy and CHIP/ID guide panels belong to the subsequent implementation threshold and must not be used to backdate the December Stage Five checkpoint.
11. Recurrence becomes runtime state
By May, two changes had converged. The large embedded chronology was replaced by a renderer that loaded its content from a JavaScript crate. Companion records followed the same pattern: appendices, claims matrix, heads of claim, CAD, GP, hospital and NHS healthcare data each had a backup crate under html/chrono-core/data/. At the same time, taxonomy and CHIP/ID crossed the boundary from a developing idea into authored relations and executable interpretation.
The browser was now functioning as an execution environment. Crates populated localStorage; renderers consumed the resulting runtime state; navigation was reconstructed from the authored content. This reduced the physical size of rendering surfaces and made it possible to revise content without rebuilding every interface.
The May checkpoint therefore established the contract on which multiplexing later depended:
crate → runtime state → renderer → navigation
At this stage that contract still had only one owner. Nevertheless, the critical separation between content and machinery had occurred.
12. Separating the record from its interpretation
The August build adds a second separation: authored relations and the grammar used to interpret them no longer need to be the same object. taxonomy-grammar-profile.js declares meaning; taxonomy-grammar-runtime.js applies it; tri-axial-data.js carries authored graph relations. The semantic chronology provides a machine-readable projection of the same graph represented visually by the primary chronology.
This is the point at which “forensic reconstruction” becomes too narrow a description of the machinery. The corpus remained forensic, but the instrument was becoming a temporal analysis machine. A different taxonomy and grammar profile could make the same underlying mechanics useful in another domain without pretending that the meanings of the original forensic profile were universal.
The Annexe also appears as a companion shell. That change matters because analytical and documentary surfaces no longer need to compete with the sovereign chronology for one viewport. The chronology holds temporal orientation; the Annexe holds the surfaces through which that graph is examined.
13. Multiplexing: separating the instrument from one continuum
13.1 The first merger
The 8 September checkpoint is the first supplied archive in which registry-driven multiplexing is visibly integrated with the Exemplar. The files graph-registry.js, graph-manager.js, case-context.js, case-route.js and the shell-profile runtime introduce an explicit answer to a question the earlier system never needed to ask: which graph owns this request?
The initial answer used case-* identifiers. That vocabulary was subsequently corrected because graph identity is a directory and runtime ownership mechanism, not a declaration that every graph is a legal case.
13.2 Directory scope replaces implicit ownership
By 30 September, the graph had become a directory-scoped object under archive/file-*/. Its data, assets and ribbon profiles travelled with it. Shared system renderers remained under html/; graph-specific material belonged to the graph. The registry declared what could be selected, while file-context.js established the active identity for each rendering surface.
This preserved the original runtime model instead of replacing it. The graph still becomes runtime state and the renderers still reconstruct navigation from it. Multiplexing adds an ownership envelope:
registry selection → graph context → graph crate → scoped runtime state → shared renderer
The envelope must be removed before an internal date, node, appendix or document fragment reaches the existing surface logic. That is how the chronology remains reusable rather than being rewritten for every graph.
14. The present operating contract
| Layer | Present responsibility | What it must not assume |
|---|---|---|
| Registry | Declares available internally stored graphs and supports runtime-linked instances. | That one graph is permanently authoritative for all surfaces. |
| Directory scope | Provides graph-owned data/, assets/, HTML, guides, actions and provenance. | That the graph must occupy one fixed physical drive or host location. |
| Graph context | Resolves identity, resource paths, storage keys and named windows before shared machinery runs. | That a filename alone identifies its owner. |
| Crates | Carry authored graph state, profiles, ribbons and surface-specific content. | That the shared renderer contains graph meaning. |
| Shared renderers | Interpret the selected crates and construct the requested surface. | That GO1NR161, or any other graph, is built into the renderer. |
localStorage | Provides the runtime bus where URL capacity is insufficient and surfaces must share constructed state. | That unscoped keys can safely serve several simultaneous graph instances. |
| Named windows | Keep chronology, Annexe and document workspaces stable and separate for each graph or mounted instance. | That names such as chronology, ANNEXE or document can remain globally singular. |
| External broker | Supplies on-access resources from a directory selected by an authorised user. | That access authority or credentials should be invented or managed by the instrument. |
15. Closing the ownership leaks
The September merger made hidden single-graph assumptions observable. Subsequent work did not change the epistemic model; it brought inherited components into conformity with it.
- Graph context and navigation were restored to registry- and directory-driven operation.
- Graph-owned crates and ribbon profiles were resolved from the selected graph rather than a privileged exemplar identity.
- Chronology, Annexe and document windows gained graph- or mount-specific identities.
document.htmlestablished its graph identity without changing authoreddocument.html#…links inside chronology crates.- The asset router expanded logical asset references at runtime, preserving graph-agnostic authored data.
- Dispatch stopped routing graph-owned material through hard-coded GO1NR161 locations.
- Externally selected graph directories could be linked into the live registry and consumed on access without copying the corpus.
- Graph-specific surfaces were separated from reusable Annexe renderers; absence now fails within the selected graph instead of silently leaking to another graph.
- Closing the final Annexe tab restores its graph-scoped authorable Ready State.
- Legacy manifest provenance remains readable while current manifests retain the newer crate form.
16. What the instrument preserves
The successive builds are not replacements for unrelated systems. The same core method persists throughout:
- events are fixed to time;
- records descend to source material;
- node taxonomy states what kind of event is being represented;
- CHIP/ID grammar exposes recurrence and relation without substituting itself for evidence;
- runtime construction reduces the burden of carrying a large graph through URLs or static pages;
- analytical surfaces examine the same underlying record from different directions.
What changes is the degree of abstraction. April could operate because one corpus and one interface were inseparable. May separated content from rendering. August separated authored relation from interpretive profile. September separated graph ownership from the instrument. October repaired the inherited routes and runtime identities exposed by that separation.
17. Making reconstruction reproducible
The authoring system and Exemplar remain reciprocal but are not the same application. The Exemplar is the operating reference implementation and publication surface. Authoring extracts its valid production contracts from that working system and produces the graph, grammar and taxonomy crates that the Exemplar consumes.
The April template author demonstrates why this relationship cannot be described as a conventional software specification followed by implementation. The initial author formalised node shapes already proven in the live reconstruction. Later authors and profiles were then lifted from further proven structures. The Exemplar is both upstream evidence for Authoring design and the downstream consumer used to test Authoring output.
Exemplar → Authoring → graph crates → Exemplar
The former single-graph operating path has now been phased out. html/index.html is the common registry entry regardless of registry size, and graph-manager.js renders that registry even when only one graph is published. Selecting the graph supplies the identity required by its chronology, Annexe and companion surfaces. The remaining one-entry inference in file-context.js is a defensive resolution for a direct, unscoped chronology.html request; it is not the former behaviour in which a sole graph replaced the registry and loaded its own shell into the common entry.
18. What the record establishes—and what it does not
This progression distinguishes what the archives prove from what would require a separate reconstruction:
- The archives prove the presence and evolution of the listed files, contracts and interfaces.
- They prove that taxonomy and CHIP/ID pre-date multiplexing.
- They prove that content was externalised into crates before graph ownership was generalised.
- They prove that registry/context routing appears in the September merger and that
file-*directory scope follows. - They do not turn a small test graph into an equivalent second corpus.
- They do not establish that every feature present in a directory had already completed every planned authoring workflow.
A full second graph with comparable assets, companion surfaces, semantic depth and internal relations would take substantial time to construct. It is unnecessary for proving separation mechanics. A compact conformance graph may later exercise one representative of each routing class, but it would test contracts rather than reproduce the Exemplar’s cognitive depth.
19. The continuum reconstructed
The central achievement is not that a website became a larger application. It is that a sequence which had been divided across institutional records can now be examined without surrendering the relationship between origin, repetition, reframing and consequence. The graph holds propositions beside their sources, distinguishes an originating event from its later institutional description, and preserves contradictions that would otherwise disappear when each organisation considers only its own fragment.
HNK marks the decisive turn because the documents were present and apparent progress had been made. The failure did not arise from an empty file. It arose when a civil committal was renamed, the substituted category controlled jurisdiction, and the continuum was partitioned around that substitution. The later passage of the frame into the Legal Ombudsman process shows why reconstruction had to follow representations as they travelled, not merely collect the events to which they referred.
Each major construction stage answered a limitation exposed by that task. Static prose recovered the narrative. Linked HTML reduced the cost of documentary descent. The common shell resisted fragmentation between analytical domains. The hero-map experiment asked how a route through the whole could be represented. Node taxonomy and CHIP/ID made recurrence explicit. Runtime separation and multiplexing finally distinguished the sovereign graph from the machinery used to interpret it.
The result is a machine that remembers the continuum without deciding it in advance. It does not make an institutional allegation true by presentation, and it does not replace the underlying evidence. It removes the advantage created when memory, files, jurisdictions and professional scopes are fragmented—and requires the sequence itself to be confronted.
