§29 Final Analysis

Direct answers, tied to the system that actually exists.

1. Why is the current Research Publisher ineffective?

Because it derives 6 relationship edges from 756 documents while the corpus supplies at least 878. 99.1% of published research is an isolated node.

The mechanism is specific and fixable: normalize.mjs's alias table omits the keys the corpus actually uses (document_type, related_documents, superseded_by, source_rep, …), and graph.mjs then reads only camelCase ID lists and silently discards any edge whose target it cannot resolve.

Three compounding effects follow: 708/756 documents collapse to the generic type research-document, 742/756 to researchArea: "General Research", and 735/756 to a hardcoded created date of 2026-07-22. The result is a site where every facet is degenerate and nothing links to anything.

2. Presentation problems vs ROS-format problems?

Neither, mostly — they are parser/contract problems. Of the eleven weaknesses catalogued in A.14, eight (W1–W6, W10, W11) are contract defects in the publisher. Two (W7 sub-document objects, W9 URL derivation) are design defects. One (W8, catalog bloat) is an output-shape defect.

The ROS formats are heterogeneous but entirely machine-readable. No corpus change is required.

3. Can the existing ROS research corpus be used unchanged?

Yes. 116 of 117 authored documents have parseable front matter (the 117th is an archived duplicate with none, which is still publishable). All 49 authored and 520 frontier IDs are unique. 878 relationship instances resolve. The nine dangling references are legitimate research states to be surfaced, not fixed.

4. What is the real canonical research object model?

A document, identified by an optional declared id, carrying free-text status, purposes/audiences (the only near-universal fields, 112/117), an optional typed link to a research-execution package (source_rep), and a heterogeneous related_documents list.

There is no canonical sub-document research object. No finding, claim or evidence item has an identity anywhere in the corpus. The only sub-document handle in use is a frontier record's section: field, matched by heading text.

5. Which relationships can the publisher safely derive?

Safely and totally: backlinks, same-project, shared-concept, frontier-of, supersession chains. Partially, with explicit confidence: section anchors (fragile under rewording) and cites-same-source (citation normalisation is lossy). Never: finding→evidence, contradicts, supports — the corpus does not encode them, and inferring them is forbidden by §28.

6. What should the first page of a research project show?

Purpose (from the entry-point REP), then the open frontier — the 520 structured frontier records are the corpus's densest and best-linked data, and are currently invisible as anything but undifferentiated pages — then research position, in-flight work with pending obligations, and integrity.

Not "recent activity": the dates are fabricated, and showing them would be a lie.

7. What should Limen own?

Only browser capability: document, window, history, location, fetch, clipboard, storage, DOM events. The kernel paints what it is handed and reports intents. It must not interpret a reference value, a status phrase, a ranking, or the difference between canonical and derived relationships.

8. What should remain static HTML?

Every artifact page, the project landing pages, and the collection pages — generated by the F# core at build time, readable with JavaScript disabled. Limen is an enhancement layer for search and relationship traversal, never a precondition for reading research.

9. What should the F# core own?

Discovery, parsing, the domain model, validation, relationship resolution, projection, index generation, URL minting, search-index construction, and tests. Everything in tiers 1–3.

10. What should block publication?

Five things only: duplicate artifact id, duplicate published URL, unreadable source file, an output path escaping the output root, and a previously published URL disappearing without a redirect.

11. What should only produce warnings?

Dangling references (9), bare-filename references (6), missing ids (68 of 117), missing declared type (49 of 117), orphans, and malformed facet values (1). These are the ordinary condition of live research.

12. What existing URLs/contracts must remain stable?

/collections/{facet}/{value}/ (175 pages — the only navigation that works today) and every currently published document URL, via permanent redirects. research-catalog.json v1.1 as a one-release shim. ROS's own files are not the publisher's to touch.

Worth stating plainly: 58% of authored document URLs are already unstable, because they derive from titles. "Preserve existing URLs" is a weaker promise than it sounds.

13. What should the first vertical slice implement?

The composition-science project — 23 documents, four artifact types, and the only fully-resolving typed relationship in the authored corpus (four artifacts joined by source_rep: RP-COMP-005). Parse → type → validate → resolve → index → static page → Limen view → navigate experiment-report ↔ REP with working back/forward → publish to Pages → tests.

14. What should explicitly be deferred?

Search, the other seven projects, Git-history timeline, findings/contradiction views (the corpus cannot support them), collection-page redesign, and retiring the v1.1 catalog.

15. What assumptions in the current requirements were wrong?

There is no vNext requirements document; the implicit ones are in docs/research-publisher-architecture.md. Wrong: that the repository had no legacy to preserve (true of the engine, false of the 837-file corpus it consumes); that front matter is camelCase; that status is a small vocabulary; that relationships are ID lists; that references means internal references; that semantic layouts were being exercised (they cannot be, with 93.7% of documents identically typed).

16. What requirements were missing?

A relationship-fidelity target; a prohibition on fabricated data; visibility of dangling references; bounded agent retrieval; consumption of the existing frontier pipeline; a URL-stability guarantee; sub-document addressability; integrity as a first-class view; awareness that 69% of published records are machine-generated; and build determinism.

17. Is static-first/GitHub Pages still appropriate?

Yes, comfortably. 756 documents parse, render and index in 5.6 seconds total. The 6.3 MB catalog is a design defect (4.0 MB of inlined HTML), not evidence of scale. Bounded retrieval works in two static fetches. Nothing in the corpus needs a server.

18. What is the simplest architecture that satisfies the evidence?

One F# program that reads Markdown, builds a typed model, resolves relationships, writes sharded JSON and static HTML; a thin Limen kernel over an F#→WASM engine for interactive navigation; GitHub Actions to Pages. No database, no framework, no server, no graph engine.

The corpus is small. The relationships are already there. The work is almost entirely in reading it honestly.