Spec Studio

An approved part of the graph reaches engineering as a read-only projection

spec:decisions.design-locked-by-projectionDecision Record · featuredefined floor ready

Next rung ready: nothing blocks; it waits only for the author's statement.

Packs: none

Design: no design entries · no pinned declarations · no decisions

Findings: no errors, no warnings

specs/decisions/design-locked-by-projection.sdp.md

No open questions and no blocking questions; implementation binding none, verifier binding none, and expected-outcome oracle none.

Intent
outcome
Decide how a design stays locked while it is implemented.
Decision
context
The owner said on 30 October that the graph, for example what is approved, scheduled or requiring design review, can be delivered to the engineering fleet as a projection, read-only while it holds that status, and "This is the only way to have a design basically locked before implementation starts."
decision
When a part of the graph reaches an agreed status, it is delivered to the target repository as a read-only projection: the selected Specs with their ancestors, the decisions behind them and every Spec their text mentions. The repository refines and implements against it, and its own gate refuses any edit to it.
rationale
  • Hard to reverse: it fixes how design and implementation meet in every project. Surprising without context: the design lives in HQ's corpus and a copy sits in each repository, yet the copy is a projection, regenerated and never edited. A real trade-off: a session cannot edit a locked Spec, so a change to its text goes back to HQ. The session still refines it in its own Specs and annotates its code against it, in whichever carrier the repository uses, so the relationship between design and code stays managed from both sides.
alternatives
  • A status inside the protocol that blocks work: SDP's conformance is "never workflow-gated", so the lock belongs to the projection and the receiving gate.
  • Only a brief: a context bundle ends with its session, and code cannot bind to it.
  • Delivered pieces the repository may edit: possible file by file, and the owner expects it to be cumbersome.
consequences
  • Approval is the owner's edit that states ready. Implementing a delivered Spec before that raises SDP's drift alarm, and stating ready clears it.
  • An implemented fact lands on HQ's own Spec in the receiving graph, so HQ reads delivery across repositories at read time.
  • A repository that will go public names no HQ Spec in its code. Its anchors land on its own Specs, one private link Spec ties those to HQ's, and HQ reads delivery through that link. Dropping the delivered folder leaves a repository that validates and names nothing private.
  • sdp validate does not see the lock, so the receiving gate checks the projection against a hash manifest. File permissions do not survive git.
  • Any process and any architecture can sit on this, because the status that selects a part of the graph is a query, not a protocol state.
Verification

Verifier bindings

No verifier binding recorded.

Design view

Requirement drawing

  • Declared verifying examples: no declared verifying example.
  • Satisfying or referencing units: no recorded binding.
  • Test or oracle bindings: no recorded binding.
Requirement drawing for spec:decisions.design-locked-by-projection

Arrows: refines (declared).

The diagram as text
  • spec:decisions.design-locked-by-projection: An approved part of the graph reaches engineering as a read-only projection · declared Spec
  • spec:hq.session-handoff: HQ hands a settled piece to a detailed session · declared Spec
  • spec:decisions.design-locked-by-projection refines spec:hq.session-handoff · declared — settles how a settled design reaches the engineering repository and stays locked
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred and chosen syntax: requirementDiagram; exact refines, satisfies and verifies, with claim words in nodes and per-edge comments.

Decisions

No decision record named.

Runtime

No implementation neighborhood recorded.

Runtime observation: not tracked.

Evidence

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

Impact
Relations of spec:decisions.design-locked-by-projection
  • E2: decidedBy · declared — the ruling makes a read-only projection how an approved design reaches the session
The diagram as text
  • spec:decisions.design-locked-by-projection: An approved part of the graph reaches engineering as a read-only projection
  • spec:hq.session-handoff: HQ hands a settled piece to a detailed session
  • spec:decisions.design-locked-by-projection refines spec:hq.session-handoff · declared — settles how a settled design reaches the engineering repository and stays locked
  • spec:hq.session-handoff decidedBy spec:decisions.design-locked-by-projection · declared — the ruling makes a read-only projection how an approved design reaches the session
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: flowchart. Chosen syntax: labelled flowchart, preserving exact relations, claims and folds.

Rests on

Rested on by

Distance 1

Distance 2

Distance 3

Distance 4

Distance 5

Distance 6

Relations

Relation and directionOther endClaimReasonExercised keys
refines · outgoingHQ hands a settled piece to a detailed session
spec:hq.session-handoff · resolves
declaredsettles how a settled design reaches the engineering repository and stays lockedNone
decidedBy · incomingHQ hands a settled piece to a detailed session
spec:hq.session-handoff · resolves
declaredthe ruling makes a read-only projection how an approved design reaches the sessionNone

Bindings

Implementation binding: none

Design reference: none

Verifier binding: none

Expected-outcome oracle: none

Runtime observation: not tracked.

Run results: not recorded in the graph.

Findings

None.

Composing (0)

Composing needs the script.