strata Explore the idea

Strata · Developer Preview

Source control
for intent.

Many agents. Shared intent.
Clear ownership.

Version what an application must do. Let agents propose changes in their own Layers. Carry behavior, constraints, and decisions forward in reviewed Releases. Materialize supported intent as code, then test the result.

Try the conflict explorer How code is produced

Developer preview · Finite workflows · Self-hosted Studio

Three agents working in their own Layers. Three amber Layers share published intent at baseline R0. Each agent proposes a change only in its own draft. Lifting a Layer opens the view; height grants no priority or authority. This is an authored illustration. R0 Shared published intent

Lift a Layer. See its changes.

  • Agent A proposes rejecting confirmation after expiry.
  • Agent B proposes showing time remaining.
  • Agent C proposes preserving hold exclusivity.

Authored illustration · Read shared published context. Write only your own Layer.
Lifting changes the view; it grants no precedence or authority.

Durable sourceIntent, logic & decisions

Replaceable outputA working implementation

The code can change.
What you learned should carry forward.

Five ideas.
One coherent application.

Bound the intent. Propose changes. Choose a candidate. Resolve its interactions. Publish a baseline backed by evidence.

  1. 01
    BlockA bounded unit of intended behavior, with a contract, requirements, relationships, and acceptance criteria.

    A Block is not necessarily a file, component, or service. Its contract says what must hold, so another implementation can be judged against the same behavior.

  2. 02
    LayerOne actor’s immutable, revisioned proposal against a pinned baseline.

    Each actor writes only its own Layer. Published revisions stay unchanged; updates create a new revision. Declare exact peer dependencies and assumptions.

  3. 03
    CompositionAn immutable candidate pinning the baseline, considered and selected Layer revisions, scenario, and Resolutions.

    Visible proposals are not automatically selected. Selection order grants no precedence. A candidate can remain blocked while its interactions are reviewed.

  4. 04
    ResolutionAn authorized, revision-bound decision settling a specific interaction.

    Decisions bind to exact proposals and required authority. New behavior must first be authored in an owned Layer; explanatory text cannot invent a rule.

  5. 05
    ReleaseAn immutable, approved semantic snapshot with provenance and validation evidence.

    Validated flattening preserves effective intent and obligations for the next baseline. A Release is not a deployment; each new realization needs fresh evidence.

A Composition is a candidate. A Release requires a tested realization and the necessary approvals.

A mental model · Target, not a proven general capability

Think of it as
semantic compression.

Keep the application’s intended behavior, constraints, and reviewed decisions in a durable representation. The implementation can change. Compression here means preserving meaning, not reproducing identical source bytes.

Target model: working application → distill semantics → Strata Blocks, Layers, constraints and intent → three independently materialized candidates, each judged by the same acceptance tests with fresh evidence.
Consistent independent reconstruction is an ambition and a test criterion. Three implementations would each need to pass the same acceptance tests; these outputs are illustrative candidates.

Today’s profiles recognize finite intent. Arbitrary application synthesis, complete extraction, and guaranteed behavioral equivalence are not established. A new realization needs fresh evidence; changed intent returns through a reviewed Layer.

A contract for agent collaboration

More agents.
Clear responsibility.

Use your existing agent framework through the CLI, or connect a separately configured coding-agent runner to self-hosted Studio. Strata defines how proposals become shared, reviewed application intent.

  • Shared context. Read authorized published intent across Layers.
  • Owned proposals. Write only to your own Layer; pin dependencies on peer revisions.
  • Explicit decisions. Route interactions to the responsible authority before publication.

A repeatable coordination pattern as work spreads across agents: follow who changed intent, which peer revisions it depends on, and who approved the decisions.

Illustrative simulation

Two useful changes.
One shared decision.

A coupon and a shipping rule can each make sense alone. Compose them and the question becomes visible: which subtotal counts?

No actual code is generated or tested in this demo.

Read the example: The base checkout is $60 with free shipping. Layer A adds a $15 coupon and checks the $50 threshold after discount: $45 + $7 = $52. Layer B checks the original subtotal: $60 with free shipping.

With both proposals, their shipping rules conflict. Keep both contributions visible, block the preview, and resolve which shipping rule applies. Choosing the discounted subtotal gives $52; choosing the original gives $45. Neither choice is validation. A real Release still needs implementation checks and required approval.

Enable JavaScript to toggle the Layers, choose a policy, reopen the decision, and simulate the separate validation gate.

This example makes a declared conflict explicit; it does not demonstrate automatic discovery of arbitrary contradictions. A real Resolution selects proposed behavior at exact revisions. Changed rules require reviewed owned proposals and authorized decisions.

Choose how intent
becomes code.

A pinned implementation profile is a recipe: supported intent, stack, configuration, template versions, and checks. Templates supply the component, handler, and storage patterns that produce actual code.

Reviewed intentbooking.checkout

Confirm a booking
only while its hold is active.

  • Behavior
  • Design
  • Data
  • Safety
  • Rule

    Reject confirmation after the deadline, including a direct command.

  • Experience

    Show the deadline, explain expiry, and make the expired action unavailable.

  • State

    Represent a valid hold and preserve its exclusivity.

Facets overlap on requirements. Labels help review; they add no authority.

Illustrative future web profileProposed

One promise.
A concrete implementation recipe.

Stack
TypeScript · React view · Worker handler
State
Versioned storage adapter
Recipe
Pinned templates, dependencies, and validators

Illustrative generated artifacts

  1. Checkout.tsxDeadline, explanation, and action state
  2. confirm-booking.tsAuthoritative active-hold check
  3. hold-store.tsHold representation and exclusivity
  4. expiry.test.tsBoundary and direct-command checks
Evidence for the actual output

Review rendered states. Exercise the command at expiry. Bind results to the exact candidate, profile, and generated files.

RequirementApplicable targetsArtifactsEvidence

A profile without a rendered view cannot fulfill this checkout experience. Uncovered or unsupported obligations block complete validation.

Developer Preview: The core supports exact-reference composition and finite implementation profiles. Self-hosted Studio adds intent browsing, owned drafts and explicit review actions. A bounded Windows Codex path has demonstrated a real proposal, an owner-saved draft, original-result recovery and Stop. The complete approved Release → saved Profile → Local Build journey is unfinished; completing and qualifying that flow follows publication. The web recipe above is a future profile. See implemented, tested and planned capabilities.

Intent travels
in both directions.

Start with software that exists, or with a reviewed model. Keep people, working previews, and acceptance evidence in the loop.

DISTILL

From application to intent.

Inspect existing code and observed behavior. Propose intent with source traceability; people review which observations should become requirements.

MATERIALIZE

From intent to application.

Realize an exact candidate or Release under a pinned implementation profile. Produce working code, then preview and test that particular output.

  1. Existing applicationCode + observed behaviorDISTILL
  2. Review owned LayersPublish reviewed proposal revisionsNew intent can start here.
  3. Pinned CompositionSelect exact published revisions
  4. Review interactionsAuthorized Resolutions where needed, pinned to exact revisions
  5. Candidate previewRealize the exact candidate with a pinned profile
  6. Test, review, approveAcceptance criteria + human review + required approvalsBlocked checks return to owned Layers.On pass: validated flattening
  7. ReleaseImmutable intent + evidenceRetain as the next baseline.MATERIALIZE
  8. Executable applicationRelease + pinned implementation profile
  9. Preview + testEvidence for this particular realizationFindings return to owned Layers.

Feedback returns through revised owned Layers and review.

A candidate is previewed, tested, reviewed, and approved before Release. Every new realization needs its own evidence.

An experimental foundation.
A broader direction.

Explore the model

Try the core: Start with the repository’s deterministic local demo. It uses fixture identities and finite examples, with no model or cloud calls. Read getting started and the implemented contract.

Self-host Studio: The development setup targets a Linux Node 22+ host behind HTTPS, your own Cloudflare Artifacts account and namespace, and a separately installed Windows coding-agent runner. Installation, permissions and native-host qualification remain explicit. This website is a static educational site.

Build in public: Follow the roadmap and verification boundaries. Profile → Build completion, unattended qualification and broader profiles remain ahead. General application synthesis and guaranteed reconstruction are not established.