What changes when intent becomes the source?

01What does Strata version, and why would I need it if I already use Git?

Direction · Model · Prototype boundary

Strata versions what the application is meant to do: its contracts, requirements, relationships, acceptance criteria, and proposed changes. Agents work in owned Layers that state their intent and the exact context they depend on.

The goal is clearer, more coherent development as more agents contribute. By composing intended behavior before realizing it, Strata aims to reduce repeated implementation, keep decisions visible, and make integration review easier to follow. Generated code still has to work and pass validation.

Git can store these records and remains a useful foundation. Strata supplies the collaboration rules around them. The local prototype demonstrates a bounded version of that workflow; comparative gains in human effort, software quality, cost, and speed remain to be measured.

Semantic compression is a mental model: preserve intended behavior, constraints, and reviewed decisions while allowing implementation details to change. Independent implementations would be judged by the same acceptance tests, each with fresh evidence. This remains a target criterion, not a claim of identical source bytes, guaranteed equivalence, or universal regeneration. See the target model and try the illustrative conflict explorer.

Reducing unnoticed intent drift and regressions is a value under test. The completed local booking-fixture pass detected seeded regressions and stale substitutions, preserved tested obligations, and accepted deliberately changed intent with fresh measured evidence. These finite synthetic cases do not establish general bug prevention, model comprehension, a reliability rate or superiority over RAG.

02What exactly is a Block, and how does it relate to a Layer?

Model · Prototype

A Block identifies a bounded part of the application's intent. It need not correspond to one file, service, UI component, or task. The unchanged default v0.1 contract stores Blocks as strict JSON with seven required fields: id, parent, purpose, requirements, acceptance, relationships, and contract. Extra top-level fields are rejected; revision and provenance belong to the surrounding snapshot and derived records. Shape validation alone does not establish profile support.

An explicitly selected v0.2 Block adds two required fields, description and asset_refs, for nine in total. Descriptions are readable plain-text/1 background and may be empty; they do not replace requirements or acceptance. Asset refs pin retained background bytes. In this version, requirements need at least one resolvable acceptance reference, and inherited acceptance references and criteria cannot silently disappear. Existing v0.1 records are not relabeled or migrated.

A Layer is one actor's revisioned proposal to change intent relative to an exact baseline. One Layer can change items in several Blocks. Several actors can propose different changes to the same Block, each in their own Layer. Owning a Layer does not give an actor exclusive ownership of the Blocks it mentions.

For example, booking.hold can be a Block. “Extend its expiry from 600 to 900 seconds” is a change proposed by a Layer. See the worked example. The repository's current Block contract provides the nested fields, valid examples, validation stages and errors. There is no dedicated .block or Markdown importer.

03Does every Layer contain every Block? Are these whole copies or deltas?

Model · Prototype

A Layer records proposed changes and their context; it is not another complete application snapshot. Unchanged Blocks and items come from the pinned baseline. A Layer does not need to repeat them, and merely reading a Block does not make that Block a change owned by the Layer.

The effective candidate combines that baseline with the selected proposals, subject to their checks. A Release stores the resulting complete snapshot, so using it as a new baseline does not require replaying old Layers.

In the model, creating a new Block requires its complete definition. That operation is deferred in the current prototype, which supports item updates and added Layer acceptance criteria.

04Is the application a flat array of Blocks, a tree, or a graph?

Model

There are distinct structures. Proposed v0.1 gives Blocks a rooted responsibility tree: each non-root Block has one parent. Separate relationships such as requires, consumes, and constrains can cross that tree. Behavioral relationships may be cyclic; the parent tree may not.

Layers have their own exact-revision dependency graph, which must be acyclic. They are not the levels of the Block tree.

Nesting helps route responsibility. It does not imply that every parent requirement is copied into each child, or that a nearer rule overrides another active obligation. Actual contracts, relationships, constraints, and affected consumers determine what must be considered.

05Are Layers like OSI layers, where each one only sees its neighbors?

Direction · Model · Prototype boundary

An actor with project read access can inspect published Layers across its authorized project, including proposals outside the current selection. Visual height and adjacency impose no read boundary and grant no priority.

Working drafts are private to their owner through the ordinary mediated API. An actor writes semantic changes only in its own Layer. Reading a peer's proposal neither selects it nor authorizes changing it. The separate local backup operator may export all indexed private history from a quiesced Node state; export rights are not inherited by readers or authors, and its destination must be authorized to receive that intent.

The prototype enforces those draft and ownership rules when its fixture principal is trusted. The public fixture handles and local filesystem remain trust boundaries; see identity and trust.

See the five core concepts on the main page.

06Is “one Layer per agent” just a new name for “one branch per agent”?

Model · Prototype

Both give parallel work an identifiable place. A Git branch points into commit history. A Strata Layer is an owned proposal to change intended behavior, with an exact baseline, expected prior values, dependencies, assumptions, and acceptance obligations.

That structure lets composition check declared relationships between proposals and preserve the choice of what becomes part of the application. Publishing a Layer makes it available; it does not silently select it or override a peer. Each Layer has one writer, and an actor can own more than one Layer.

The intended advantage is a collaboration unit that agents and reviewers can reason about directly. Whether it reduces their total work compared with a well-designed branch workflow is an open empirical question.

07What must an agent pin after reading another agent's work?

Model · Prototype

An informational read records context. A required peer read also declares an exact Layer dependency, and that exact published revision must be selected. If B relies on A@1, selecting A@2 does not silently satisfy B's dependency.

A Layer pins its baseline and expected prior values; its assumptions are checked against the final effective candidate. Relevant dependencies must be declared and reviewed; the engine cannot reliably infer them from prose.

The model discusses references to newly proposed entities and reviewed baseline migration. Today's prototype requires a common baseline and does not create Blocks or patch a Block existing only in an unreleased peer proposal. A revised owned proposal can update peer dependencies on its existing baseline. Work on a different baseline requires a new Layer identity; revising or restoring the existing Layer cannot change its baseline. Applicable checks and evidence must be fresh.

08Why not let 100 agents use 100 Git branches and merge them into main?

Direction · Model · Prototype boundary

That can work. As agents produce more changes, the difficult part is keeping their combined behavior coherent: identifying overlapping work, revisiting stale assumptions, choosing between alternatives, and reviewing the result.

Strata approaches those problems by making intended changes and dependencies explicit before building a candidate. The aim is fewer avoidable implementation merges and less human effort reconstructing why agents made their choices. Where a profile can realize the combined intent, it can build from that candidate instead of reconciling separate generated versions.

This moves integration work; it does not remove it. Ambiguous goals still need decisions, undeclared interactions can be missed, and the realized application still needs tests and review. Clearer intent, improved coherence and reduced repeated work or review effort are hypotheses to evaluate; comparative superiority over Git has not been measured.

09What is a semantic conflict, and can Strata actually detect it?

Model · Prototype limitation

Two different writes to the same requirement are an exact-target conflict. A semantic conflict can also involve different targets: one proposal expires a hold after 600 seconds while another permits its payment through 900 seconds without renewal, despite the rule that payment needs an active hold.

The prototype checks exact records, structure, declared dependencies and assumptions, and the finite scenario capabilities declared by a candidate, including booking-specific compatibility checks. People or agents can report additional interactions. It does not discover every contradiction in arbitrary prose.

Missing or unknown required checks block readiness. Undeclared requirements or unreported interactions can still escape detection. Passing the recorded checks is evidence for a bounded claim, not proof that the intent model is complete.

In v0.2, open project interaction-report/2 records carry into renamed candidates and later baselines. A new report can block pending decision packets and endorsements even when executable bytes are unchanged. Responsible review must supply an exact evidence-bound correction or nonapplicability disposition for that selection; prose or an executor cannot dismiss the report. A disposition does not cover changed future candidates or rewrite earlier Releases. This conservative carry-forward can add review work; general relevance detection is unproven.

10Who decides which proposal wins? Does a higher Layer outrank a lower one?

Model · Prototype boundary

No Layer wins through height, recency, application order, or agent seniority. Responsibility comes from the baseline's pinned authority manifest.

The proposed routing rule finds the smallest assigned scope covering all affected Blocks, consumers, and constraints, moving upward when necessary. Protected requirements can have additional guardians. Uncertain impact requires broader review, rather than a conveniently narrow decision.

A human or authorized actor endorses exact decision or candidate content under those rules. Even an authority authors semantic repairs in its own Layer. A proposal cannot grant itself authority by changing its owner or position. The prototype enforces fixture operation and optional Layer/Block assignments, but fixture endorsements do not demonstrate autonomous decision quality. Production authentication, delegation and independently authenticated evidence remain unfinished.

One fixed booking policy is now demonstrated locally: for its exact 900/1,200-second hold alternatives and reminder dependency, it selects the whole 900-second hold and reminder proposals and rejects 1,200 seconds. A trusted fixture assignment and fresh selector authorize only that covered selection. Extra or ambiguous inputs stay unresolved for human review or deferral. This is one bounded rule, not a general policy engine or model mediator; the executor cannot author behavior or supply scope, guardian or Release approval.

11Can a Resolution invent a compromise or cherry-pick half a Layer?

Model · Prototype limitation

A Resolution records an authorized decision about exact proposals. It cannot introduce behavior that exists only in the decision's explanation, waive an unchanged invariant, or secretly discard part of a selected Layer.

If two proposals say 900 and 1,200 seconds and the desired compromise is 1,050, someone must first author that intent in a separate owned Layer. Extracting part of a proposal likewise produces a new Layer with recorded lineage and fresh validation.

The model includes whole-proposal selection, evidence-backed coexistence, selection of a separately authored replacement, and deferral. The current resolver implements sealed whole-proposal select/reject decisions. Its decision proposal is published in a separate decision-only Layer; it is not a free-form merge editor.

The new local mediation path freezes exact source material and decision options in a packet. Only an authorized approve_selection response naming the exact packet, digest, case revision and option can create an endorsement. Deferring, requesting context or giving new planning direction does not approve a selection. New desired behavior still needs owned authoring. There is no timer-based acceptance or automatic retry loop.

12Where do CI, working previews, and human review fit?

Model · Prototype

They remain essential. A candidate with no known semantic blocker is only eligible for validation. It still needs an actual realization under a pinned implementation profile, passing acceptance evidence, review where required, and the required authority endorsements before Release.

Evidence binds to the exact candidate, profile, output, checks, and relevant inputs. Reviewing one realization does not approve a later changed output. People must be able to inspect working behavior, including interactions that cannot be established from prose alone.

The prototype runs the fixed booking application through its fixture runner and imports bound results. The runner compares measured output with host-supplied expectations drawn from reviewed intent, rather than trusting generated configuration. New Node profiles bind actual checker, fixture and semantic-oracle content; legacy evidence remains separately labeled. The host's expectations and checks can still be wrong. This is not general CI integration or independent proof that any claimed test was executed; its evidence trust boundary is described below.

In opt-in v0.2, a Block-changing Layer also needs an accepted authoring review before publication. An explicitly assigned reviewer receives the exact normalized draft bytes; the immutable review binds the project, draft digest and intent-authoring/1 checklist. Publication requires its exact review ref. This creates no new right to browse another owner's private drafts, and default fixtures deny the review operation. Changed draft content needs a new review. These local fixture attestations are separate from realization evidence and Release approval. Configured v0.2 fixtures now support versioned Resolution and Release with strict approval/2 bindings, fresh validation, required responsible-scope and fixed-guardian approvals, and separate Release approval. A selection decision or passing checks alone cannot publish.

13Does flattening combine every Layer and then delete the originals?

Model · Prototype

Flattening publishes the effective snapshot of one validated Composition: its pinned baseline, selected whole Layer revisions, applicable decisions, obligations, evidence, and approvals. Merely published or considered alternatives are not automatically included.

The resulting complete semantic snapshot can serve as a baseline without replaying its selected Layers. Git commits also reference complete trees; Git does not need to replay every historical patch to recover a snapshot. Strata's distinction is the intent, obligations and acceptance gates represented by that checkpoint.

Flattening preserves source revisions, previous baseline, lineage, contributing decisions, and per-item provenance. Rejected alternatives remain historical material; their rejected behavior does not enter the effective snapshot. Selected Layer acceptance obligations survive in the Release and its next baseline. Missing required validation prevents a Release.

14After a Release, how do the next baseline, undo, and rebase work?

Model · Prototype limitation

A Release contains a complete immutable semantic snapshot. Choosing it as a new baseline is explicit; publication does not automatically move ongoing work to it. Personal context show/use helps navigation but does not change an existing Layer's baseline or supply implicit mutation inputs.

If R1 contains a 900-second expiry, a new Composition based on R1 still has that rule even when it selects no new Layers. Omitting the old expiry Layer does not restore 600 seconds.

An undo is a new owned proposal against R1, with the correct expected value and fresh validation. Alternatively, an older Release can anchor separate work. The model describes reviewed baseline migration, but the current CLI rejects changing an existing Layer's baseline by revision. Author a new owned Layer identity for work on another baseline.

layer restore CURRENT --from PRIOR appends a new private revision using an older revision of the same owned Layer on the same baseline/model. History remains, and accepted review, evidence and approvals are not copied. Separate Node backup commands recover an isolated inactive archive; they do not roll back a deployment or customer runtime data. Automatic rebase remains deferred.

The new migration preview pins an exact v0.1 source Release and its digest, preserves its obligations, and proposes v0.2 with empty descriptions and asset refs plus explicit blockers. It returns applied: false. It does not import URLs, change authority, switch a baseline or apply a migration to an active project.

Separately, the local v0.2 replay demonstrated deliberate evolution: later owned proposals changed reminder/expiry from 840/900 to 1,140/1,200 seconds, with actual fresh Node evidence and separate approvals. Earlier Release bytes stayed unchanged and stale approvals were refused. This is semantic evolution, not deployment rollback.

Follow the intent-to-application workflow on the main page.

15Does the same Release always regenerate exactly the same code?

Model · Prototype limitation

No general byte-for-byte promise is made. Deterministic composition of pinned semantic records is different from reproducible generation of an arbitrary application.

An implementation profile pins a realization recipe: supported intent, materializer/template version, toolchain and dependencies, configuration, and validation methods. Reproducibility depends on that recipe and its environment. The current fixed profile has a bounded vocabulary; that does not establish deterministic future model-based generation.

Another profile may produce a different implementation of the same Release. Its output needs its own evidence. The semantic Release stays immutable; old test results do not prove new output correct. A Release is also not a deployment or a guarantee of exhaustive behavioral equivalence.

The default v0.1 booking-node/1 and opt-in v0.2 booking-node/2 keep their distinct legacy fingerprints and evidence formats. New Node-only booking-node/3 (v0.1) and booking-node/4 (v0.2) bind actual checker implementations, fixture inputs and host-supplied semantic expectations in evidence format 2. Profile 4 also retains background asset closure outside executable resources. Changing a check while keeping its label requires fresh bound evidence.

Configured v0.2 can now publish a local Release after fresh validation and its separate approvals. The local Agents SDK demonstration used asset-free legacy profile 2; SDK binary retention and checker-bound profile execution remain unsupported. No general profile loader or arbitrary application generator is provided.

16If generated code is ephemeral, does code quality matter? Can I fix it directly?

Direction · Model · Prototype

Code still runs the application. Its correctness, security, performance, operability, and debugging quality matter. “Ephemeral” means it is replaceable as an implementation, not disposable evidence or an excuse to ignore defects.

A manual fix changes the realized artifact and invalidates evidence bound to its previous bytes. If the fix changes intended behavior, carry that change back into a reviewed owned proposal. If it corrects a realization or profile choice while preserving intent, validate the changed realization under its recorded profile context.

DISTILL is that code/observation-to-proposal direction. Today it records a supplied proposal with enumerated source digests and review; it performs no automatic inference. Existing bugs must not silently become requirements. The current CLI does not automatically reconcile hand edits. No lossless code-to-intent-to-code round trip is promised; artifact retention is a separate operational decision.

17Are Design, Data, Behavior, and Safety different kinds of Block?

Classification proposal · Prototype subset

There is one Block concept. These are overlapping facets on requirements, with derived summaries for Blocks. A deadline display can involve behavior, design, data, and safety together.

Design intent can describe reading order, states, copy, interaction, accessibility, or a required visual reference. Data intent can describe meaning, integrity, and lifetime. Concrete framework or file choices normally belong to the profile unless they are themselves required.

Facets guide attention and coverage. They do not create a database, enforce privacy, appoint a guardian, or prove implementation. A complete requirement remains one editable item. The prototype recognizes the four facets, but its fixed profile rejects unsupported obligations, including unsupported visual-design promises.

The default v0.1 contract still treats Markdown, URLs and code-looking text as opaque strings, without a renderer/importer or enforced no-code rule. A reference in prose does not retain its bytes or authorize fetching or model upload.

Opt-in v0.2 adds plain-text descriptions and hash-pinned background PNG/baseline-JPEG references. Descriptions and background refs supply context; they cannot become acceptance subjects or substitute for normative requirements. Structural text checks reject specified code-like forms, but cannot prove arbitrary prose contains no implementation code. Exact-draft authoring review remains necessary.

An explicitly assigned local operator may import one supplied file into a stopped v0.2 Node state. Import is denied by default and requires project-private visibility acknowledgement, provenance/rights, and rights for internal retention and backup. Exact descriptors and blob hashes bind the bytes; logical revisions retain their predecessors. Limits include 4 MiB per file, 32 retained versions and 16 MiB of unique blobs per project. A changed file cannot satisfy an old byte hash; older retained versions remain addressable.

Assets are supporting records, not a sixth semantic object. Only the background role with empty subjects is enabled; images do not enter executable resources. Structural PNG/JPEG validation is not full decoder or malware certification. PDF/video, SVG, rich Markdown, remote media imports, extraction, model uploads, deletion and SDK binary retention remain unavailable.

See the implementation-profile example on the main page.

18What stops an agent from impersonating another owner or approving its own work?

Prototype limitation · Planned security

The default local demo uses trusted fixture identities. Its broker maps known fixture handles to principals; semantic operations enforce Layer ownership, exact revisions and required endorsements. A process that knows a fixture handle can use that principal. These checks do not establish production isolation.

Opt-in self-hosted Studio has a separate installation-owner login, named engine actors, explicit operation grants, protected credential storage and revocable namespace consent. A reader session, owner sign-in or agent pairing does not automatically grant Release authority. The finite first-project setup can explicitly assign one person several roles; it does not provide independent reviewer separation. Broader production identity, delegation and multi-tenant isolation remain unfinished.

A prompt, role name, Git commit author, content hash or successful Cloudflare login is not proof of Strata review authority or independently authenticated execution. Evidence and approvals remain bound to their exact candidate, output and configured trust boundary.

Content review and asset import require explicit assignments and remain denied without the appropriate grant. Fixture review labels, named human review and native agent output have different trust boundaries; none should be presented as independent production certification.

The bounded mediation fixture uses one-use receipts tied to the exact covered selection. Concurrent requests, lost responses, restarts and retry-cache eviction were exercised locally: retries recovered the same endorsement without replenishing authority. Generation, expiry and withdrawal checks still apply. These synthetic fixture permissions and receipts are not authenticated human consent, cryptographic execution attestations or production account security.

19How does an existing coding agent learn Strata? Is Strata the orchestrator?

Developer preview · Bounded agent integration

Strata supplies semantic records, checks, and a CLI contract. The existing host or orchestrator assigns work, supplies tools and context, supervises execution, and manages permissions. An agent can prepare proposals through that interface; it does not acquire approval authority merely by being the lead agent.

The repository supplies a portable skill, the current Block contract, an initial manifest and a full example replay. The full replay is reference material: a host loads relevant steps rather than treating every record as an initial prompt. Human-readable help exposes current limitations and backup integrity fields; JSON remains the automation contract.

Self-hosted Studio also supports an explicitly paired coding-agent runner. The bounded Windows Codex path has demonstrated a real proposal, explicit owner Save as draft, original-result recovery and fresh Stop. Those attended checks do not qualify unattended use, every machine or the full Release/Profile/Build journey. Other adapter implementations need their own qualification. The moving agents and checkout conflict explorer on this website remain authored illustrations; they generate and test no actual application code.

20What works today, what is still missing, and what do the scale claims mean?

Developer preview status, assessed October 15, 2026

The domain-neutral core dispatches declared capabilities. Booking profiles, the counter fixture and finite collection profiles exercise bounded vocabularies. Unsupported intent fails closed. Every realization needs fresh evidence; supplied proposals alone do not establish reconstruction.

The roadmap table separates implemented code, the checks actually performed and the next work. Public status does not mean production readiness. Setup and resource permissions remain explicit.

The historical local stress workload used scripted Layers; publication was serialized. It did not measure concurrent LLM development, current production throughput or productivity versus Git. No scale or reliability claim follows from a synthetic test count.

Broader production identity, general policies, SDK binary/checker parity, active migration and general reconstruction remain unfinished. PDF/video and broader media processing remain unavailable.