Agent-EA v2 — Architecture findings (data fidelity)

Agent-EA v2 — Architecture findings (data fidelity)

Recorded 2026-05-30 while validating the transgesco reference against the D1 proof. This is the key "potential problem" the engine must solve to be genuinely reusable.

Finding 1 — D1 and the published data.js are two divergent models, not source→generated

The shipped transgesco pages render from a hand-authored data.js (PUBLISHED="20 mai 2026"). The D1 TES catalog (experiments/dae-catalog-d1/transgesco-seed.sql) is a separate LeanIX extraction. They do not match:

D1 TES catalog Published data.js
Shape flat objects + relations + attrs JSON nested MAP / SVC / PROJ / CHG / PHWIN / JALONS / FLOWS / DATA
Object model LeanIX types: Objective, Platform, Initiative, Org, Business Capability capability rows with dec/crit/pro[]/role/app/cmp/vendor/op/opex/vol/src
Tagging attrs.tags = A-codes (A100, A200…) structure-by-page (each const feeds specific pages)
Process detail none full FLOWS (SIPOC, steps, gateways, BPMN)
Roadmap none PHWIN windows + JALONS milestones

Consequence: "D1 is the single source of truth; HTML regenerated from it" is not true today. The shipped pages cannot be reproduced from D1 — the editorial richness lives only in data.js.

Why a naive "everything in D1" fix is wrong

Forcing the full nested page model into objects.attrs JSON turns D1 into a JSON blob store and defeats its only advantage (queryable, cross-mandate catalog). The FLOWS/SIPOC/BPMN and roadmap timeline are presentation/curation, not architecture facts you query across clients.

Resolution — two-layer model (refines spec §4/§5)

Layer 1 — D1 catalog (source of truth for architecture FACTS). objects + relations + CO + derived gaps. LeanIX v4. Queryable, portable, cross-mandate. This is exactly what ea:leanix-catalog-extract already produces. Drives the inventory/catalog pages: A200, A210, A219, A250, catalogue-changements, fiche-changement, fiche-projet.

Layer 2 — curated deliverable model (data.js, per-DAE, in the client portal repo). The narrative/process/roadmap structures (FLOWS, PHWIN, JALONS, the editorial MAP rollup with decisions) that reference Layer-1 catalog IDs. Hand-curated; this is the editorial craft that made transgesco land. Drives the editorial pages: A100 synthesis, A230 orientations, A270 roadmap, 14-* processes.

export-datajs.mjs generates only the Layer-1 portion of data.js from D1 (the catalog/inventory/CO arrays). The Layer-2 curated portion is authored and version-controlled alongside the client portal. The two are concatenated into the page-facing data.js.

What this changes in the plan

  • D1 stays lean and queryable (no FLOWS/roadmap forced into attrs).
  • The "regenerable from D1 alone" success criterion (spec §1 #2) is scoped to the catalog layer, not the editorial layer. State this explicitly.
  • The template pack splits: catalog templates (data-driven from D1) vs editorial templates (curated data.js). Only catalog templates are fully D1-generated.
  • seed.mjs/export-datajs.mjs target Layer 1. A separate, smaller curate-datajs convention documents the Layer-2 hand-authored block.

Finding 2 — reconcile the two existing transgesco models before reuse

transgesco-seed.sql (D1) and the published data.js were built independently and have drifted (different capability groupings, different cost figures, A-code vs structural tagging). Before the Transgesco follow-on mandate, one reconciliation pass is needed: treat the published data.js as the editorial truth and the D1 catalog as the queryable fact base, and align IDs so Layer-2 can reference Layer-1. Do not assume either is canonical without that pass.