Publication Model

The bridge between the Intelligence Platform’s truth and the Lovable-designed portal experience. It defines who owns what, how truth becomes destination data, and the rules that keep the published portal evidence-first. This document is the contract’s preamble; the field-level contracts are in Lovable Data Contract, the mechanics in Publication Pipeline, the entities in Publication Entity Catalogue, the rules in Publication Validation, and the sequence in Implementation Roadmap.

Design stance. The Publication Model is itself an instance of the ecosystem’s architecture: it is deterministic (generated, reproducible), contract-first (versioned immutable feeds consumers pin), knowledge-referenced-never-owned (Lovable references truth, never copies or authors it), honestly-labelled (every feed carries a status; missing data is stated, never invented), and human-approved before publish. It obeys Architecture Principles 1, 3, 8, 11 and Operating Principle O2.

1 · Ownership — the two layers

graph LR
  subgraph CLAUDE["Claude — the Truth Layer"]
    REPO[Source repositories] --> DIG[Digests · markdown estate]
    DIG --> GRAPH[(Portfolio Graph)]
    GRAPH --> HEALTH[(Health Engine)]
    GRAPH --> PUB[/Publication feeds/]
    HEALTH --> PUB
  end
  PUB ==>|versioned, read-only contract| LOV
  subgraph LOV["Lovable — the Presentation Layer"]
    COMP[Components · layouts · motion] --> SITE[Published portal]
  end
  classDef c fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef l fill:#eef0f4,stroke:#8079ff,color:#333;
  class REPO,DIG,GRAPH,HEALTH,PUB c;
  class COMP,SITE l;

• Claude owns the truth layer. Source repos, the markdown estate, the Portfolio Graph, the Health Engine, every generated JSON feed, all entity data, provenance/evidence, status and maturity labels, routes, ADRs, principles, and governance. Claude decides what is true.
• Lovable owns the presentation layer. Components, layouts, visual and motion design, the destinations’ look and interaction, and navigation UX. Lovable decides how it looks.
• Neither crosses the line. Lovable never authors truth (no invented facts, metrics, or relationships). Claude never styles (no component or CSS decisions in the truth layer).

2 · The boundary

The boundary is a set of published, versioned, validated JSON contracts under publication/, indexed by a manifest.json. Lovable consumes them read-only and pins a manifest version (exactly as the assessment engine pins a pack version — Principle 3). A feed only crosses the boundary after it passes validation and a human approves it.

content/editorial/           # Claude-owned authored narrative (INPUT, not shipped raw) — §7
publication/                 # the immutable, versioned contract Lovable pins
  manifest.json              # versions · feed statuses · source hashes · shard registry · schema registry
  routes.json                # route manifest for link resolution
  navigation.json            # the single navigation source Lovable consumes — §5-nav
  search-index.json          # the single search source Lovable consumes
  portfolio-graph.json       # the graph (existing truth)
  health.json                # the deterministic Health snapshot (existing truth)
  evidence-plates.json       # claims → sources → status
  canonical/
    spine.json               # THE Platform Spine — defined once, referenced everywhere (§9)
  destinations/
    arrival.json
    story.json
    portfolio-gallery.json
    flagship-experiences.json   # (was "flagship-experiences") — §8 naming
    architecture-gallery.json
    intelligence-products.json
    reference-library.json
    engineering-manual.json
    living-platform.json
  schemas/                   # JSON Schema for every feed above
live/                        # RESERVED — future Live feeds (mutable, TTL); never mixed with publication/ — §8

3 · Source-of-truth hierarchy

When two sources disagree, the higher one wins:

1. Source repositories (CLAUDE.md, README, ADRs, pack manifests) — the ground truth of what is built.
2. Markdown estate (portal/**) — Claude’s evidence-first digest of the repos (factual truth). 2E. Editorial Source Layer (content/editorial/**) — Claude-owned authored narrative truth (§7). A sibling of the estate: it owns how the platform is narrated, never what is factually true.
3. Portfolio Graph (portfolio-graph.json) — the structured projection of the estate.
4. Health Engine (health.json) — deterministic metrics over the graph.
5. Publication feeds (publication/**) — destination projections of graph + health + editorial source.
6. Lovable render — presentation only; carries no authority.

A publication feed may not assert a fact not traceable to level 1–2, nor a narrative not traceable to level 2E. Editorial decisions choose emphasis, narration, and ordering — never facts. Lovable owns none of these levels — it consumes level 5 read-only.

4 · Feed tiers (honest labelling)

Every feed and entity is labelled with one tier. This is how the model stays evidence-first while defining the complete contract Lovable designed for.

Tier B feeds are projections of existing truth — building them invents no data, only re-shapes it. Tier C feeds ship as valid but empty (schema-conformant, status:"awaiting", populated arrays empty) so Lovable can render “Awaiting” states without special-casing.

5 · Generated vs authored

Ownership correction (pre-freeze): authored narrative previously lived inside Astro/Lovable presentation. It now lives in the Editorial Source Layer — a Claude-owned tier. Lovable never authors editorial truth.

Generated feeds are reproducible: given the same estate commit, the same bytes come out (no Date.now() — the graph already uses generatedAt: null; feeds are versioned by content hash of their source, not wall-clock).

6 · Missing-data rules (the safety core)

The single most important rule set. Lovable render-safety depends on these.

1. Never invent. No feed asserts a metric, artefact, relationship, maturity, or sample output not traceable to source. If it isn’t in the graph/estate/repo, it does not appear as fact.
2. Missing is explicit. Absent data is represented, not omitted silently: every optional entity/field has a status ∈ {live, buildable, awaiting, missing, planned} (or a sibling _status), and awaiting/missing/planned collections ship as empty arrays with a status, never absent keys.
3. Placeholders, not gaps. Lovable renders an explicit “Awaiting evidence” / “Planned” state for awaiting/planned; it must not fabricate filler or hide the element as though complete.
4. Evidence or silence. A claim without a resolvable source is downgraded to status:"awaiting" and its value suppressed — the contract carries the claim shell, not an unsourced assertion.
5. Maturity is honest. planned/in-progress never render as implemented. Labels come only from frontmatter/digests (Principle 8).

7 · The Editorial Source Layer (Claude-owned narrative truth)

Authored narrative is a first-class Claude-owned tier, not presentation. It is the canonical source for all human-written copy the destinations render.

• Owns: Arrival narrative · Story chapters · Portfolio Overview narrative · Gallery introductions · Product introductions · Manual introductions · captions · editorial transitions · featured artefact/diagram selections.
• Does not own: any fact (facts stay in the estate/graph) — only how they are narrated and ordered.
• Folder structure:

  content/editorial/
    arrival.md            # hero eyebrow/headline/lede/CTAs
    story/                # one file per chapter: prose, takeaway, transition, featured refs
      01-the-problem.md … 10-the-idea.md
    overview.md           # Portfolio Overview narrative framing
    galleries/            # intro copy per gallery (portfolio, architecture, products)
    flagship/             # per-flagship selection + narrative framing
    captions.md           # evidence-plate & diagram captions
  

  Each file carries frontmatter (id, destination, status, last_reviewed) and marks factual claims with an EvidenceRef so validation can separate narrative from fact.
• Ownership: Claude (human-authored, human-reviewed). Presentation (Lovable) is a consumer, never an author.
• Approval: editorial content is claim-bearing narrative → human-approved (§8) before publish.
• Publication: generators read content/editorial/** + graph/health → destination feeds. The editorial layer is an input, never shipped raw to Lovable.
• Regeneration: an editorial file change regenerates only the destination feed(s) that consume it.

8 · Feed classes & publication classes

Two orthogonal taxonomies replace the earlier “everything is an immutable versioned feed” assumption.

Feed classes (by mutability/lifecycle)

Live feed rules (reserved — do not implement): a Live feed is mutable, carries a TTL and refreshedAt, is not version-pinned by Lovable (Lovable polls/subscribes and honours the TTL), uses cache rules (cache-control/stale-while-revalidate semantics), an approval model of “schema-approved once, data flows unattended” (the contract is human-approved; individual updates are not), and a version policy of “the schema is versioned; the payload is not.” Live feeds are physically separated from the publication/ immutable tree (e.g. a live/ namespace) so they never contaminate the reproducible set. This reservation lets telemetry/streaming arrive without redesigning the static/generated contract.

Publication classes (by content origin & approval)

Every feed is tagged feedClass + publicationClass; the pipeline routes it to the matching approval gate. Auto-publishable feeds (Reference/Generated, no new claims) may publish on trigger without per-run human sign-off — enabling scheduled publishing later without a redesign. Claim-bearing/Editorial feeds always require human approval (nothing customer-facing auto-ships — O2).

9 · The Canonical Platform Spine (single source)

There is one platform value chain. Every destination references it; no destination redefines it.

Knowledge → Capabilities → Intelligence Products → Applications → Ventures → Customer Outcomes

The canonical spine is defined once in publication/canonical/spine.json (a Reference feed). arrival, architecture-gallery, and story reference it by id — they must not inline their own stage lists (validation rule spine-single-source, validation).

10 · Entity model — System vs Venture

The earlier model conflated two distinct concepts under one type. They are now separate first-class entities:

• System — an internal grouping of repositories that delivers capability, positioned in an architecture layer (e.g. Shared Skills, Intelligence Platform, Applications & Agents). These are the 3 current graph venture-kind nodes, retyped system.
• Venture — a business the platform serves (Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats). Ventures are reserved as first-class entities; today they are awaiting (documented as businesses, not yet registered as graph entities). They must never be conflated with systems again.

Both appear in Portfolio Gallery and Reference Library; the Canonical Spine’s stage 5 is Ventures (business), not systems. See the Entity Catalogue.

11 · Scaling reservation (index / detail / shard / page)

Feeds are simple today (one file per feed) but the envelope reserves scale so growth needs no redesign:

• A feed may declare itself an index (shape:"index") that points at detail feeds (shape:"detail") — Lovable loads the index, then details on demand.
• A feed may be sharded (shards:[{path,hash,range}] in the manifest) or paged (page/pageSize/nextPage).
• The manifest enumerates every shard/page so integrity and routing still hold.

Today every feed is a single file (shape:"single"); the fields above are optional and unset. When reference-library or evidence-plates grow past a size budget, they convert to index+detail without a contract change — the shape was reserved from day one.

12 · Core questions — answers

13 · What must never happen

• A destination renders a number, artefact, or relationship that isn’t in the truth layer.
• A planned/awaiting item renders as done.
• A feed ships without a schema, a status, or resolvable evidence for its claims.
• Lovable authors or edits truth, or Claude ships a component/style decision.
• A published feed version mutates in place (versions are immutable; supersede, never rewrite).