Delivery Sequencing: Dependency Graph & Priority Ranking¶

Structure (this site's page groups, reflecting architectural dependency) and priority (where Neosframe's own effort should go next) answer different questions and deliberately diverge twice. Nothing here has been scoped down to engineering-days.

Built against a window that is no longer confirmed

This ranking was derived with the six-week alpha window as a real constraint (Home → Target deadline). The relative order still holds regardless of how much time there turns out to be; any absolute pacing implied by it should be read as provisional. The Resolver Engine's own timeline is now decoupled from Composer's entirely, so it appears below as an external delivery, not as work this team schedules.

Structure versus priority¶

Structure reflects what depends on what: Foundations genuinely sit underneath everything else. Priority reflects where Neosframe's own effort needs to go next, which is a different question when part of the foundation — the Resolver Engine — is an external delivery with its own owner and its own timeline, and the rest is Composer's own design and build. The ranking below is derived from the graph, then adjusted by named judgment calls. Two deliberate departures from pure dependency order:

UI — dependency order puts it late, but its historically rough track record and the fact that it's what BSR will see argue for starting UX and UI exploration in parallel with backend work. A recommendation offered for Blair's own sequencing call (Editing UI & Canvas), not a decision overriding it.
Concurrency locking — pushed down despite dependency order clearing it, because it's not needed for the alpha at all (Concurrency & Editing Safety).

Dependency graph¶

graph LR
    A0["Alpha acceptance criteria<br/>(scope gate, not a code dependency)"]
    R0["Resolver Engine — Text Foundation<br/>(core BUILT; consolidation +<br/>layout-shape correction outstanding)"]
    R1["Resolver Engine — pin (reserved, unimplemented)<br/>+ flowBox / background / targetFraction /<br/>price / cues / keyframes (not started)"]
    CH["Change model &amp; mutation engine"]
    SC["Elements / Scenes / Projects schema<br/>+ Overlays, identity &amp; versions, brand"]

    KF["Keyframes &amp; cues, Composer side<br/>(deferred)"]

    ST["Storage tables"]
    FR["Fork / rebase mechanism"]
    PT["Permission tiers"]
    PE["Server-side enforcement<br/>(checkChangeTier)"]

    UC["Canvas UI<br/>(shown to clients, gated by tier)"]
    UA["Element-authoring tool<br/>(gated by tier)"]

    CL["Concurrency locking<br/>(design for; not built in alpha)"]
    TP["Testing / preview / incident response"]
    AI["AI-agent forward-compatibility<br/>(deferred)"]

    A0 -.scopes.-> CH
    A0 -.scopes.-> SC
    A0 -.scopes.-> UC

    R0 --> R1
    R0 --> SC
    R1 --> SC
    R1 --> KF

    CH --> PE
    CH --> FR
    SC --> PT
    SC --> ST
    SC --> CL
    SC --> UA

    PT --> PE
    ST --> FR
    PT --> UC
    CH --> UC
    FR --> UC
    PT --> UA
    PE --> UA

    PE --> UC
    PE --> AI
    FR --> TP
    UC --> TP
    PE --> TP

    classDef scopeGate fill:#F3E8FF,stroke:#9333EA,color:#581C87,stroke-width:2px
    classDef root fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A
    classDef external fill:#E0F2FE,stroke:#0284C7,color:#075985,stroke-dasharray: 6 3
    classDef tier1 fill:#CCFBF1,stroke:#0D9488,color:#0F4C46
    classDef critical fill:#DCFCE7,stroke:#16A34A,color:#14532D
    classDef ui fill:#FEF3C7,stroke:#D97706,color:#78350F
    classDef deferred fill:#F1F5F9,stroke:#64748B,color:#334155,stroke-dasharray: 4 3

    class A0 scopeGate
    class CH,SC root
    class R0,R1 external
    class PT,ST tier1
    class PE,FR,TP critical
    class UC,UA ui
    class CL,AI,KF deferred

One edge is deliberately not drawn

The Change Model raises the live possibility that the Change model needs the engine's flowBox / pin to be schema-stable first (because of setInstanceLayout), which would make the engine's second stage a dependency of the Change model, not just of the schema. That's an open question, not a settled fact, so the graph doesn't draw it as a hard edge; drawing one would overclaim certainty the other way. Treat the Change model's position as a root as provisional until that question resolves.

Reading the graph without Mermaid¶

Violet — scope gate, not a technical dependency: alpha acceptance criteria (Process & Organisation). Everything below can be built without it, but nobody can confidently decide how much of it to build without it.
Blue — Foundations, the technical roots: the Change model; the Element/Scene/Project schema with its Overlays, identity/versions, and brand pages.
Sky, dashed — the Resolver Engine, an external delivery at two stages: Text Foundation (core built, two pieces outstanding — including the consolidated text type an Element's layer list is written against), then everything else Composer's Elements are made of (not started). Not two independent roots — one delivery, two milestones — and not this team's schedule (The Resolver Engine Dependency).
Teal — first band: permission tier definitions; storage tables.
Green — alpha-critical: server-side enforcement; the fork/rebase mechanism; testing/preview/incident response.
Amber — UI: two pieces with different profiles. The canvas shown to clients is dependency-last but risk-early, so exploration should start in parallel; the Element-authoring tool needs the schema and the tier design (create, edit, brand/org assignment), so it folds into the same UI planning session rather than starting as an independent, ungated track.
Slate, dashed — deferred: concurrency locking; AI-agent forward-compatibility; Composer's side of keyframes and cues.

Priority ranking¶

Alpha acceptance criteria (Process & Organisation) — gates the scope of everything else, even though it isn't a code dependency. The hardest, and confirmed unresolvable by asking BSR; Neosframe defines this itself or it doesn't get defined.
The Change model & mutation engine (The Change Model) — the single most depended-upon technical artifact in this design; provisionally a root, per the undrawn edge above.
The Element / Scene / Project schema (Elements, Scenes & Projects, Overlays, Identity, Versions & Schema Versioning, Brand Scoping & Brand Style) — gates storage, tiers, and UI.
Permission tiers + server-side enforcement (Permissions & Enforcement) — nothing can be shown to an external client safely without at least a coarse version of this, and it's built on a tier boundary that is a deliberate, unvalidated guess.
Storage (Storage & Versioning) — gates persistence of anything Composer produces.
Fork/rebase (Fork, Rebase & Conflict Resolution) — needed almost immediately once more than one version of anything exists in real use.
Canvas UI (Editing UI & Canvas) — the largest raw effort, dependency-last but risk-early, so UX exploration should start now, in parallel with 2 through 5 — a recommendation for Blair's call, not a decision made here. The Element-authoring tool is not a separately startable track: it needs 4 as well as 3.
Testing / preview / incident response (Testing, Preview & Incident Response) — planned early, even though it's built late.
The Resolver Engine (The Resolver Engine Dependency) — architecturally the foundation everything above sits on, but ranked here for Neosframe's own Composer effort because it is an owned, external delivery on its own timeline: Text Foundation's core is built, its point/box consolidation and layout-shape correction are not, pin is reserved in the schema but unimplemented, and flowBox, background, targetFraction, price, cues, and keyframes are Matthew's own unstarted build. Composer's planning consumes its status; it doesn't schedule it.
Concurrency locking (Concurrency & Editing Safety) — not part of the alpha build. Design the schema and Change model so it can be added later; don't implement the lock/heartbeat mechanism until post-alpha.
Keyframes & cues, Composer side (Keyframes & Cues, from Composer's side) — not required for Composer's structural-editing job; the engine owns the system itself.
AI-agent forward-compatibility (AI / Agent Forward-Compatibility) — lowest priority. The protocol wrapper is close to free once 2 through 5 are done properly; the swap-suggestion half needs per-Element capability descriptions and is not free at all.

Risks¶

Any single first-band or alpha-critical item turning out far larger than its position implies once actually attempted — nothing here has been scoped down to engineering-days.
Actual team capacity to run bands in parallel versus serialising them, given ad hoc staffing.

Open questions¶

Whether this sequencing survives contact with whatever the alpha acceptance criteria turn out to be — a narrow-enough target could compress several tiers into one another.
Whether the Change model depends on the engine's schema stability (the undrawn edge).