Spec Studio

Capability epics keep kind independent of altitude

spec:decisions.epics-of-any-kindDecision Record · featureready floor ready

New since the base graph base da4b141. See the diff.

Base input: schema 0.11.0, 405 Specs.

Packs: pack:roadmaps-and-slices-v1, pack:self-hosting-v1

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

Findings: no errors, no warnings

specs/decisions/epics-of-any-kind.sdp.md

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

Intent
outcome
Decide whether a capability map admits epics of every kind or only behavior epics.
Decision
context
The glossary row for capability and domain names a Capability Map over high-altitude behavior Specs, while kind and altitude are independent descriptors on the one primitive, and the hubs that already state the Protocol's capabilities include a domain model, a projection model and the rule that separates the two check families.
decision
Any Spec stated at epic altitude is an epic, whatever its kind, and keeps its kind: the capability map reads every epic and its refinement descendants, and the glossary row broadens from high-altitude behavior Specs to epic Specs of every kind.
rationale
  • Hard to reverse: corpora organize their capabilities around which Specs may be epics, and the capability map, its page and the upgrade guide read that choice. Surprising without context: the ratified glossary row limited the map to behavior Specs, so a reader needs to know why a model or a rule now heads a capability. A real trade-off: an epic of any kind keeps the Spec that already owns a capability's outcome as its head, as the one-primitive decision's named coordinates already imply, against a map whose roots differ in kind and a glossary row that changes.
alternatives
  • Keep behavior-only capability epics and introduce behavior wrappers over the model and rule hubs: each wrapper would restate an outcome another Spec already owns, a second owner that drifts, only so that a view can read it.
consequences
  • The capability map draws epics of every kind, each labelled with its kind, and a Spec's kind never decides whether it heads a capability.
  • The glossary row for capability and domain names a Capability Map over epic Specs of every kind and their refinement descendants.
Verification

Verifier bindings

No verifier binding recorded.

Design view

Requirement drawing

  • Declared verifying examples: no declared verifying example.
  • Test or oracle bindings: no recorded binding.
Requirement drawing for spec:decisions.epics-of-any-kind
The diagram as text
  • spec:decisions.epics-of-any-kind: Capability epics keep kind independent of altitude · declared Spec
  • spec:consumers.capability-map: The capability map reads every epic and its refinement descendants · declared Spec
  • impl:protocol.capability-map-recipe: asserts realization of The capability map in docs/agent-surface/recipes.md · anchored code · test/recipes.test.ts:7602
  • spec:decisions.epics-of-any-kind refines spec:consumers.capability-map · declared — settles which Specs the capability map reads as epics
  • impl:protocol.capability-map-recipe references spec:decisions.epics-of-any-kind · anchored
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: requirementDiagram. Chosen syntax: flowchart TB because references require exact labels unavailable in requirement syntax.

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.epics-of-any-kind
The diagram as text
  • spec:consumers.capability-map: The capability map reads every epic and its refinement descendants
  • spec:decisions.epics-of-any-kind: Capability epics keep kind independent of altitude
  • spec:decisions.one-primitive: One Spec carries named delivery coordinates
  • spec:protocol.capability-epics: The Protocol organizes its own features in capability epics
  • spec:decisions.epics-of-any-kind dependsOn spec:decisions.one-primitive · declared — kind and altitude are independent named coordinates on the one primitive
  • spec:decisions.epics-of-any-kind refines spec:consumers.capability-map · declared — settles which Specs the capability map reads as epics
  • spec:consumers.capability-map decidedBy spec:decisions.epics-of-any-kind · declared
  • spec:protocol.capability-epics decidedBy spec:decisions.epics-of-any-kind · declared
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

Relations

Relation and directionOther endClaimReasonExercised keys
dependsOn · outgoingOne Spec carries named delivery coordinates
spec:decisions.one-primitive · resolves		declaredkind and altitude are independent named coordinates on the one primitiveNone
refines · outgoingThe capability map reads every epic and its refinement descendants
spec:consumers.capability-map · resolves		declaredsettles which Specs the capability map reads as epicsNone
decidedBy · incomingThe capability map reads every epic and its refinement descendants
spec:consumers.capability-map · resolves		declaredNoneNone
decidedBy · incomingThe Protocol organizes its own features in capability epics
spec:protocol.capability-epics · resolves		declaredNoneNone

Bindings

Implementation binding: none

Design reference: present

  • impl:protocol.capability-map-recipe · asserts realization of The capability map in docs/agent-surface/recipes.md · test/recipes.test.ts:7602 · role projection

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.