Developer and Publisher

Developer is a signed-in user persona. Publisher is the durable identity that owns a namespace, immutable Releases, Offers, team membership, statements, and any future payout destination.

A Publisher role never grants runtime authority. It does not expose customer Agents, Cases, Connections, Sources, Worker credentials, or Case contents.

Publisher roles

• Owner manages the Publisher profile, membership, Releases, statements, and future payouts.
• Maintainer publishes Capability and Constitution Releases.
• Finance reads statements and prepares future payout operations.

The first-party Rulith Publisher uses the same registry, membership checks, Release ownership receipts, and market path as every other Publisher.

Private development loop

Rulith starts from real Cases rather than a blank package generator.

1. An Agent runs an Exploration Case when installed Releases do not fully cover the task.
2. A successful, certified Case becomes a tenant-private Episode only when it has exact Release attribution, a durable Attempt Trace, a terminal receipt, and redacted candidate-bearing law.
3. Distillation produces a bounded Candidate containing Vocabulary, Rules, and board-local Actions. A Candidate is not a Release and cannot be installed.
4. Deterministic replay evaluates both supporting Episodes and searched counterexamples. Missing frozen evidence, false allow, false block, conflict, corpus overflow, or a changed program fails the Candidate closed.
5. Shadow evaluation applies the Candidate to a detached clone of one Case frontier. It cannot dispatch an Action, write a receipt, change Case revision, install content, or mutate the Agent Board.
6. In Developer → Distillation, a human opens a current Shadow report as an ordinary private Draft. The Draft remains editable and unpublished.
7. Publishing that reviewed Draft creates a new immutable Release under a Publisher identity and records the Candidate-to-Release promotion. Publishing is never an automatic consequence of replay or Shadow.

Shadow evaluation contract

Shadow is a governance-only control operation. Every request binds:

• Candidate ID, Candidate artifact digest, and current replay report digest.
• Candidate snapshot digest and normalized program digest.
• exact base Release digests and effective base program digest.
• target Capability Publisher and ID.
• one Case ID and exact Case revision.

The result is a hypothetical report containing observed revision, base and Candidate program digests, derived-node differences, completion comparison, Action-precondition candidates, and an independent report digest. It contains no trusted effect, terminal receipt, Case mutation, or execution grant.

Publishing

Open Developer in Console to create or select a Publisher. Drafts remain private to the user account. Publishing creates an immutable Release ownership receipt under the selected Publisher.

Capability and Constitution are the only public Release kinds. Both use the same market card and publication lifecycle. A Capability contains Vocabulary, Rules, Actions, and Sources; a Constitution remains independent governance.

A Release may publish several Case Types. Each Case Type has one Case Contract and terminal Goal. Supporting Capabilities may share prerequisites without owning or metering the Case.

Commercial boundary

Public beta payments are not active. The commercial path runs zero-rated so the service can verify Offers, Case pins, terminal usage, statements, refunds, settlement inputs, and reconciliation without moving money.

Private or tenant-distilled Capabilities are never marketplace products and never generate Publisher receivables. A public Release can become commercially eligible only through an immutable Offer and a successful terminal Case whose authority-computed path coverage satisfies the threshold pinned at Case open.

Continue with the Billing model or the Capability field reference.