Control what can leave.
Source ownership, output boundaries, cumulative disclosure and the limits of the public browser sample.
Keep the source under owner control
A capability exposes a task, rather than an unrestricted document endpoint. A caller receives the permitted result fields. The source can remain in an owner controlled environment whose access rules and lifetime are explicit.
OCLITH's public browser examples use public sample policies and caller supplied text. They do not constitute a private Vault. Use sample material when exploring them.
Three separate surfaces
Discovery exposes the capability declaration: its task, accepted input, allowed output, owner and policy metadata.
Execution processes a bounded request. Sensitive source material belongs inside its execution boundary, rather than in public registry records.
Evidence associates the request, policy, allowed result and trace. Its purpose is inspection and integrity checking; it should not become a second source data export channel.
The public directory stores Manifest declarations and owner registration metadata. It does not store Console input. Capsule exports use an input digest and input length instead of the raw input text. The policy exported by an example is the capability policy.
Output allowlists and deny fields
Each Cell declares returns and disclosure.deny. A request may ask for a subset of allowed result fields. It cannot ask for source, credentials, internalRules or memory when those are denied by the policy.
The output guard also checks the candidate result. A result with an extra undeclared field is rejected. The Console provides a diagnostic case for this check, so the guard can be inspected directly.
Cumulative disclosure
Repeated related questions can reveal more than any single answer. OCLITH separates a teaching simulation from the decisions for an actual local call.
Budget preview: teaching model v1
The homepage controls use oclith-sample-disclosure-v1. Their related-call count is simulated and never substitutes for actual ledger history:
exposure = min(100, round(calls × 0.34 + detail × 0.38 + overlap × 0.44))
Simulated calls and detail range from 1 to 100; overlap ranges from 0 to 100. At 25 the sample model masks category fields, at 48 it reduces detail, and at 72 it rejects release. A lower Manifest limit can stop release earlier.
The interface shows a score, the release threshold, their distance, and permitted fields. Distance is measured in score points relative to the policy threshold. It is not a percentage of privacy remaining.
Local ledger: rolling execution model v3
New local releases use oclith-local-disclosure-v3. Each successful event stores its execution ID, capability ID, UTC time and only that call’s original detail and overlap, together with its model and window. Its before and after snapshots remain available for record inspection, but their accumulated detail, overlap or exposure never become a new event’s contribution.
For a forecast, choose events for the current capability that remain within both the current policy window and their own saved window, taking the shorter duration. Deduplicate them by execution ID. Successful-call count comes from these events, and peaks come from their original parameters. Add the current request to predict the next release:
projected = min(100, round(nextCalls × 0.34 + peakDetail × 0.38 + peakOverlap × 0.44))
Execution recalculates this same forecast from the latest ledger and time immediately before release. The threshold is min(72, Manifest compositeLimit × 100); reaching it rejects the request. At 25, category is withheld. At 48, only the declared coarse verdict, selection or scoreBand remains eligible. A request can receive only the intersection of requested fields and eligible fields. If none remain, the request is rejected with an explicit output restriction.
Console shows the current window score, this request’s projected effect, projected score, threshold and eligible fields. Distances use score points, not a percentage of privacy remaining. Lowering the next request’s detail or overlap cannot remove another event still in the window. When that event expires, the score can decrease.
For example, with a 24h window, detail 80 released at T0 still influences a detail 1 request at T23h. A new event at T23h saves detail 1, not the cumulative peak of 80. At T25h, T0 has expired and its high detail cannot be carried forward by the newer event.
Finite legacy compatibility
An older event may have only cumulative snapshots. The Console does not invent raw parameters or silently drop a still-valid release. It conservatively retains the old snapshot’s impact until that event exits its valid window. The original window is recovered from its saved execution policy when available; if an older record is no longer retained, the currently selected policy window is the explicit fallback. The shorter of the original known event duration and current policy window determines eligibility.
The forecast reports the number of conservative legacy events and their latest exit time in Eastern Time (America/New_York), including the applicable EST or EDT suffix. Exported event timestamps remain ISO UTC. New v3 events save their own raw contribution and never copy a legacy exposure floor. The old influence therefore has a finite exit instead of being renewed by later releases.
Recording, replay and compatibility
Only a successful release appends one ledger entry for its unique execution ID. A rejected request retains a failure trace and adds no successful release. An in-flight guard prevents a double click from creating two executions. Reopening the same record never books it twice.
Replay, Pause, Resume, Copy, Download and Verify do not create a new call, regenerate its identity or spend budget. Every execution snapshot and Capsule retains its saved policy, model and score. Saved Celino v1, v2 and v3 model identifiers remain readable with their original contributions and records. Capsules from earlier protocol versions remain verifiable. Current calls do not rewrite or recalculate any historical policy, output, model, score or digest.
The teaching model and all execution model versions are public sample disclosure assessments. They are not differential privacy, mathematical anonymity guarantees or a production authorization service. A browser ledger illustrates the rule; a private production executor must enforce permission and budgets using authoritative durable state and concurrency controls.
Threat model and runtime declarations
Output restrictions limit direct disclosure. They do not establish that a private source is trustworthy, that a model cannot infer additional facts, or that a runtime is hardware isolated. An execution adapter must enforce its network access, persistence, input handling and revocation policy.
The Console does not issue TEE attestations, zero knowledge proofs or confidential execution certificates. The integrity view compares covered content with its digest. It does not certify the source or correctness of a private computation.
Owner control
An owner controls the capability declaration and can revoke a registered policy. Callers can continue to inspect prior records. Revocation changes future access decisions; it does not erase knowledge already disclosed in a permitted answer.