Development story · public technical publication

Reframe is developed as an inspectable story.

The Book follows one method from source material to a governed scenario, from implementation to witnessed acceptance, and from evidence to a bounded public projection.

A reviewed public projection · runtime implementation remains private · read the publication policy

The governing sequence

The development story has five acts.

Each act has a different authority. The Book explains the relationship; it does not replace the runtime contract or persisted proof.

  1. 01 · SourceMaterial enters with a confirmed working context.
  2. 02 · ScenarioA reusable contract names prerequisites, actors, terminal predicates, and evidence.
  3. 03 · ImplementRuntime behavior is built against the contract and its governed boundaries.
  4. 04 · AcceptAX, FountainStore, window identity, telemetry, and provenance witness the result.
  5. 05 · PublishThe Book exposes only the sanitized, reviewed projection.
MethodHow the cycle worksRead the development method and its reusable scenario seam. EvidenceWhich journeys are coveredRead the named scenarios and their publication eligibility. BehaviorWhat the runtime exposesInspect the verified development command surface.
Reader orientation

The Book mirrors development, not the application menu.

Read down the story when you want to understand the method. Move sideways to the records when you need a specific command, scenario, capability, or release boundary.

  1. 01 · MethodScenario-driven development is the organizing principle.
  2. 02 · EvidenceAcceptance remains separate from release.
  3. 03 · RecordsCommands, capabilities, scenarios, and release state answer different questions.
  4. 04 · BoundaryThe public Book is a projection, not runtime authority.
What the Book covers

Four records answer four different questions.

Keeping these records separate prevents a command count, a ready state, or a successful scenario from becoming an accidental product claim.

Inventory

What entries exist?

95 command entries in the verified development catalog. Aliases count as entries, not new powers.

Read verified behavior →
Capability

What is governed?

55 capability identities, with policy, ownership, proof, and acceptance tracked separately.

Read the capability atlas →
Scenario

What has been proven?

6 named scenarios are live-accepted in the current snapshot; 4 command pages are eligible.

Read scenario coverage →

These reviewed values are embedded in this checked publication projection, not inferred from conversational or UI wording.

How to trust the record

Claims stay attached to evidence.

Read the status as a chain, not a badge. Each step answers a narrower question.

Scenario first

A named scenario defines prerequisites, terminal predicates, and the evidence needed before a command page is eligible.

Open scenario coverage →

Acceptance is not release

AX, visual capture, FountainStore, telemetry, and provenance can establish a result without creating a released App surface.

Check the release boundary →

Development inventory is not a promise

The command atlas records what the development runtime exposes. It is not a marketplace, product catalogue, or capability allow-list.

Open the command atlas →
For maintainers and agents

The orientation layer.

Use these records as the stable map. The Book explains; the integration runtime and persisted Store remain operational authority.

Publication stateDevelopment snapshot · 2026-08-15
Release stateno-released-build · empty allow-list
Primary indexesCommands · Scenarios · Capabilities
Authority boundaryPublic projection policy · private runtime