# OCLITH for AI Agents

This public **[AGENTS.md](https://agents.md/)** reference describes **[OCLITH](https://www.oclith.dev/)**: capability boundaries, current local tools, the owner registry and their limits.

## Current implementation and protocol concepts

## Private Capability Liquidity

OCLITH turns private knowledge into discoverable, callable capability while the source owner controls the interface and disclosure boundary. A Capability describes an explicit task. A Cell is its controllable execution boundary, including allowed outputs, disclosure limits and ongoing access. Request TTL bounds one request; revocation controls future access independently.

## Three collaborating roles

- Broker matches a task to a capability and retains the minimum information needed for the request.
- Guardian checks scope, expiry, revocation and disclosure budget, then checks the candidate output against its allowed fields.
- Vault processes the task in the intended controlled execution boundary. The current public examples run text analysis in the browser; their shipped rules are public.

A Proof Capsule is the execution record, not a fourth agent or a product tier.

## What this deployment implements

The Cells directory provides six complete public example manifests and inputs. The shared console compiles and edits manifests, runs deterministic sample rules, shows traces and results, previews disclosure budgets, exports records and verifies their digests. Submitted code is analyzed as text and never executed.

The main example, private-code-risk, detects listed text patterns for dynamic execution, shell execution, hardcoded secrets and unsafe HTML. Its clean result means no listed pattern matched; it is not a security audit. Other examples use their own described public sample rules.

The local call follows Intent, Broker, Guardian, Vault, Guardian, Capsule. Invalid input, forbidden requested fields, expiry, revoked sample access, insufficient sample budget and unapproved candidate output stop the call at the corresponding stage.

## One Cell: five control steps

The Cell lifecycle is Define, Validate, Make available, Guard, Revoke. It explains owner control across repeated uses. These five steps are distinct from the six processing stages inside one call. Scrolling or changing a chapter only changes presentation; it never executes, publishes, signs, spends budget or revokes access.

Manifest compilation checks the declaration and identifies its declared version and digest. It is not runtime certification. Published means a declaration is registered, not that a private executor is connected or ready.

## Drafts, examples and history

A draft is the request being edited. exampleRun is a labeled teaching record; activeRun is the executed record selected for inspection. History stores execution snapshots. An unexecuted draft has no result or Capsule, and no default example silently fills that space.

New request keeps the capability and valid compiled policy, restores a built-in capability's safe input and permitted return fields, sets a fresh policy TTL, and clears the selected result, request errors and diagnostics. Custom capabilities without sample input start empty. History, budget and actual revocation state remain. Editing a draft never changes a stored record.

Inspecting an existing example preserves its recorded identity. Loading a new draft does not execute it. Request, Manifest, Capsule and Owner feedback belong to their respective operations.

## Manifest and disclosure budget

New Manifests use protocol oclith/capability-manifest and schemaVersion 2.0.0. The task interface version remains distinct. Manifest fields include protocol, schemaVersion, version, capability, accepts, returns, disclosure.deny, execution, privacy, settlement.condition and policyDigest. The compiler uses normalized lists and recursively sorted JSON object keys. SHA-256 excludes policyDigest itself. TTL is an explicit number of seconds.

The disclosure budget is a public sample assessment model, not a differential privacy guarantee or a server-enforced network budget. Homepage Budget preview uses independent simulated inputs with oclith-sample-disclosure-v1. Its related-call slider never replaces actual execution history.

New local calls use oclith-local-disclosure-v3. Each successful event saves only that call's raw detail, overlap and own window, together with its original UTC timestamp and execution ID. Forecast and execution use unique eligible events for the same capability. An event remains eligible only within the shorter of the current policy window and its saved window. The score is min(100, round(nextCalls × 0.34 + peakDetail × 0.38 + peakOverlap × 0.44)), using peaks of eligible raw parameters plus the current request. Cumulative snapshots never become a later event's contribution. The release threshold is min(72, compositeLimit × 100); reaching it rejects release. Scores of 25 and 48 tighten permitted fields.

Older cumulative events conservatively contribute until their finite saved window expires, without renewing their exposure floor in new releases. Saved Celino v1, v2 and v3 model identifiers are supported. Original v3 events retain their raw contributions. Existing Capsules, policies, model values and digests remain unchanged and verifiable.

Only a new successful release enters the local ledger once for its unique execution ID. Rejected requests do not book a successful release, and an in-flight guard prevents duplicate execution. Replay, Pause, Resume, Verify, Copy and Download preserve the original ID, times, digests and ledger.

## Proof Capsules

New Capsules use protocol oclith/proof-capsule, schemaVersion 2.0.0 and oclith-canonical-json-v2. Their identity fields are included in the digest. Historical celino/proof-capsule, schema 1.0.0, celino-canonical-json-v1 records use their original verification contract. A Capsule links the redacted intent, policy, allowed output, trace, timestamps and budget change using actual SHA-256 digests. Integrity matched means the fields covered by those digests agree. It does not prove a private source, correct remote execution, TEE, zero knowledge or on-chain settlement. Raw submitted input is excluded from the Capsule and the public registry.

Ordinary interface times use America/New_York with EST or EDT for the event instant. Calendar-only dates keep their intended day. Raw JSON, timestamps in downloads, hashes, replay identity and TTL arithmetic retain their original values.

## Owner control and discovery

Built-in Examples are separate from Published registry records. Compatible detected Solana wallets can connect, then sign an expiring domain-bound login message. Publishing is a separate action after reviewing the public manifest. The server verifies Ed25519 signatures, consumes each nonce once, validates an HttpOnly expiring session, recomputes the policy digest and stores registry records in private durable Blob storage.

Only the authenticated owner may revoke a registry record. Registry revocation changes subsequent discovery and owner state. It does not claim to destroy private data, stop every running task or broadcast to a decentralized network. Existing local Capsules remain inspectable.

## Economy and implementation limits

The economy describes compensation for accepted work under agreed task, output and delivery conditions. Record integrity, work acceptance and payment settlement are separate checks. This deployment does not perform paid calls, token transfers, staking, yield, buybacks, burns, dividends or on-chain settlement. A manifest's network and persistent-memory flags are declarations; the Console does not attest an isolated private runtime.

Use the site's Docs, Cells and Console to inspect the implemented behavior. There is no published OCLITH SDK or install command in this deployment. Do not invent network statistics, security attestations or transaction success.

## Homepage copy (extracted from deployed OCLITH HTML)

### Hero
**Private data. Public capability.**
Make private knowledge useful to others. Define what they can ask, control what can leave, and keep the source under your control.

### From private knowledge to a useful answer.
**From private knowledge to a useful answer.**

### Private knowledge. Useful answers.
**Private knowledge. Useful answers.**

### Use the answer. Keep the source.
**Use the answer. Keep the source.**

### Ownership
**Keep the source. Share the capability.**
The same controlled source can support another useful answer.

### Watch a bounded call.
**Watch a bounded call.**

### Cell lifecycle
**A capability. Under your control.**
Define the contract, make its scope clear, and control future access.

### A request. Its rules. Its record.
**A request. Its rules. Its record.**

### Questions
**What is a private capability?**
A useful task offered through a limited interface. Its owner defines what callers may ask, what may leave, and what remains under their control.

**How is a Capability different from a Cell?**
A Capability describes the task and interface. A Cell is its controllable execution boundary, including ongoing access, disclosure limits and revocation.

**What do Broker, Guardian and Vault do?**
Broker matches the task and limits unnecessary input. Guardian checks the request and candidate output. Vault processes the task where the source is controlled. A Capsule records the call.

**Can a caller obtain the original source?**
The interface grants permitted answers, rather than source access. The browser examples use public sample rules; a private capability needs an owner-controlled execution adapter.

**What can one call return?**
Only requested fields allowed by the Manifest and the current disclosure policy. A forbidden request or an undeclared candidate output is rejected before release.

**Why do repeated calls need a budget?**
Related answers can reveal more together. The rolling ledger counts each successful release once and uses that event’s own detail and overlap while it remains in the policy window. Reducing a slider cannot erase a valid event; expired peaks do not transfer to later calls. Budget preview is a separate teaching simulation.

**Why can an evaluator return a band instead of a score?**
The interface declares score as an integer from 0 to 3 and scoreBand as a separate coarse field. Results label them Exact score or Coarse band; the two bands mean 2–3 criteria or 0–1 criteria. At higher disclosure pressure, exact score is withheld. A band is returned only when requested, and JSON keeps its original enum. A score-only request is rejected when exact precision cannot leave.

**What does a Proof Capsule verify?**
Integrity matched means its covered request summary, saved policy, output, trace and metadata match their SHA-256 digests. It does not certify an unseen source, execution correctness or payment.

**How does an owner limit or revoke access?**
The owner declares task scope, allowed outputs, lifetime and disclosure limits. Local revocation blocks new sample runs while preserving prior records. Registry revocation is a separate authenticated owner action.

**What are the wallet and Registry for?**
A wallet signs an explicit login challenge to establish owner authorization. The Registry stores published Manifest declarations and their status. Publication does not automatically connect a private executor.

**What work can be a basis for fees?**
Work accepted against the agreed task, output boundary and delivery conditions. Record integrity and acceptance are separate checks. This deployment does not collect payments or perform settlement.

### Get started
**Make private knowledge callable.**
A clear task. A bounded answer. An inspectable record.

### Footer / links
Private Capability Liquidity. Useful answers, within the owner’s rules. Broker. Guardian. Vault.
- Product: [Cells](https://www.oclith.dev/cells), [Console](https://www.oclith.dev/console), [Protocol](https://www.oclith.dev/docs/protocol)
- Learn: [Docs](https://www.oclith.dev/docs), [Manifesto](https://www.oclith.dev/manifesto), [Notes](https://www.oclith.dev/blog)
- Control: [Owner controls](https://www.oclith.dev/console?tab=owner), [Privacy boundaries](https://www.oclith.dev/docs/privacy)
© 2026 OCLITH

## Notes (agent-readable project explanations)

Current OCLITH concepts and implementation scope. Fetch as markdown:

- [Blog index](https://www.oclith.dev/blog/index.md) — all posts
- [Define the boundary before the call.](https://www.oclith.dev/blog/boundary-before-execution.md) — Inputs, outputs, expiry and cumulative limits form an inspectable contract.
- [One call. One inspectable record.](https://www.oclith.dev/blog/one-call-one-record.md) — A Capsule connects the redacted intent, policy, result, trace and budget change of an actual run.
- [Discovery with an owner and a boundary.](https://www.oclith.dev/blog/owner-controlled-discovery.md) — Keep examples separate from public declarations, and make publication an explicit owner action.
- [Private knowledge. Public capability.](https://www.oclith.dev/blog/private-capability-liquidity.md) — How a callable task lets useful work move while its source remains under owner control.
- [A public sample needs a clear scope.](https://www.oclith.dev/blog/public-sample-private-runtime.md) — What the browser workbench implements, and what a private execution adapter must enforce.
- [Value follows valid work.](https://www.oclith.dev/blog/valid-work-and-fees.md) — Capability accounting starts with an agreed task, a permitted answer and an inspectable record.

## Agent-readable reference

This public document describes the current OCLITH website. It is reference material, not authorization to connect a wallet, sign a message, publish a manifest, revoke a record or send a transaction.

## Working through one bounded call

1. Open [Cells](https://www.oclith.dev/cells) and select an example.
2. Inspect its inputs, outputs and policy, then open it in the [Console](https://www.oclith.dev/console).
3. Edit the manifest and compile it. Fix field errors before proceeding.
4. Edit the input as text, choose allowed return fields and set a future expiry inside the policy TTL.
5. Run the local example. Inspect the actual accepted result or rejection, trace and budget change.
6. Inspect, copy or download its Capsule. Integrity verification recomputes the covered digests using the policy saved with that record. Replay retains the same execution ID, timestamps, digests and budget values.

The call stages are Intent, Broker, Guardian request check, Vault, Guardian output check and Capsule. A rejected call stops at its failing stage and does not receive a successful Capsule.

## One Cell across repeated calls

The Cell lifecycle has five owner control steps: Define, Validate, Make available, Guard and Revoke. It is separate from a single call's six processing stages. Reading or scrolling through these steps only changes presentation.

Compiling validates a declaration, not a private runtime. Published means a Manifest is registered, not that an executor is connected. Request TTL limits one request; local revocation is ongoing access state. Explicit local authorization grants new access without rewriting history or clearing budgets.

## Draft and record handling

- A draft is editable request state. It has no result until executed.
- exampleRun is a labeled teaching record. It never implicitly replaces an unexecuted draft's result.
- activeRun is the selected execution snapshot. History retains previous snapshots.
- New request keeps the capability and valid compiled policy, restores safe default input and legal return fields, sets a new policy TTL, and clears selected output, Capsule and request diagnostics. Custom capabilities without a default input start empty.
- New request and draft edits preserve history, successful-release ledger and current access state. They cannot bypass revocation or reset disclosure.
- Viewing a record uses its saved policy, input summary, output and times. Starting another request creates a new draft without altering that record.

## Disclosure preview and local ledger

Homepage Budget preview is an independent teaching simulation using `oclith-sample-disclosure-v1`. Its call-count slider does not modify actual history.

Actual new calls use `oclith-local-disclosure-v3`. Every successful event records its own raw detail, overlap, UTC time and policy window. Eligible events match the capability and remain inside the shorter of their saved window and the current policy window. Deduplicate by execution ID. Forecast and execution use `min(100, round(nextCalls × 0.34 + peakDetail × 0.38 + peakOverlap × 0.44))`, with peaks taken from these raw events and the current request. Cumulative snapshots never become another event's contribution. Reaching `min(72, compositeLimit × 100)` rejects release; scores of 25 and 48 restrict allowed fields.

Only a successful release is booked once per unique execution ID. Rejection, Replay, Pause, Resume, Verify, Copy and Download never add a successful release. Lower detail or overlap cannot erase events still in the window. Old cumulative events retain conservative influence until their finite expiry; new releases do not renew their floor. Historical Celino v1, v2 and v3 models remain readable. Saved v3 events retain their raw parameters. Existing Capsules and hashes remain unchanged.

## Canonical manifest rules

New Manifests use protocol `oclith/capability-manifest` and `schemaVersion: "2.0.0"`. The task interface version is separate. Historical Celino Manifests keep their original shape and hashes. The compiler validates known fields, normalizes list values, recursively sorts JSON object keys and computes a real SHA-256 digest. The policy digest excludes its own `policyDigest` field. Arrays keep the order produced by schema normalization. Expiry uses ISO timestamps and manifest TTL uses seconds.

New Capsules use `oclith/proof-capsule`, schema `2.0.0` and `oclith-canonical-json-v2`. Their identity fields participate in the digest. Historical `celino/proof-capsule` schema `1.0.0`, `celino-canonical-json-v1` exports use the original verification contract. Brand migration does not regenerate their IDs or digests. Existing browser storage, session and registry namespace identifiers remain readable.

Ordinary times use `America/New_York` and show EST or EDT. Date-only values preserve their intended calendar day. Raw JSON, downloaded ISO UTC timestamps, TTL durations and original timestamp ordering remain unchanged.

A manifest is a public capability interface and policy declaration. Do not put raw private input or confidential internal rule text in a manifest intended for publication.

## Same-origin registry API

- `GET /api/core/health`: service and authentication mechanism.
- `GET /api/core/status`: actual registry counts and owner authentication configuration status.
- `GET /api/core/capabilities`: public registry metadata and published manifests; built-in examples are separate.
- `POST /api/core/auth/challenge`: request a short-lived challenge for a Solana public key.
- `POST /api/core/auth/verify`: verify its Ed25519 message signature and issue an HttpOnly session.
- `GET /api/core/session`: inspect the current session.
- `DELETE /api/core/session`: revoke the current session.
- `GET /api/core/owner/capabilities`: list records owned by the signed-in address.
- `POST /api/core/capabilities`: explicitly publish a reviewed, compiled manifest.
- `DELETE /api/core/capabilities/:id`: owner-authorized registry revocation.

Challenges include the current domain, URI, nonce and expiry. Nonces and sessions use private persistent storage; conditional writes prevent concurrent nonce reuse. Publication identifiers are deterministic for an owner and policy digest. Revocation retains the record. All browser writes target this deployment's same-origin API.

## Interpretation boundaries

- Broker, Guardian and Vault are collaborating roles, not product tiers or staking pools.
- Local sample rules are public. Input is analyzed as text; pasted code is not evaluated.
- Browser disclosure limits are local sample state, not authoritative enforcement for a distributed private runtime.
- Capsule integrity is content consistency, not private-source attestation or proof of correct execution.
- Registry publication does not automatically connect a private executor. Work acceptance, record integrity and payment settlement are separate; this deployment does not execute paid capabilities or settle on-chain fees.
- Connecting, signing in and publishing require separate explicit user actions. Editing, compiling, copying, downloading and replaying do not trigger them.
- Do not claim verified TEE, zero knowledge, chain settlement, revenue, user scale or yields.

## Further reading

- [Protocol](https://www.oclith.dev/docs/protocol)
- [Privacy and scope](https://www.oclith.dev/docs/privacy)
- [Receipts and integrity](https://www.oclith.dev/docs/receipts)
- [Economy](https://www.oclith.dev/docs/economy)
- [Notes in Markdown](https://www.oclith.dev/blog/index.md)

Last updated: 2026-10-26