A public sample needs a clear scope.
Reproducible rules
The six built-in Cells each provide a complete Manifest, sample input and a public deterministic rule. They make the relationship between input, policy checks and output visible.
Code risk checks text patterns. Restricted policy checks explicit restricted terms. Research compares word overlap between two supplied summaries. Operations classifies incident signals. Personal context selects a stated response format. The evaluator scores three explicit proposal criteria.
These are different tasks with different rules. They do not share a fixed success response, and none claims access to unseen source material.
Local analysis is not private execution
The rules ship with the frontend. A caller can inspect them. The browser analyzes the supplied input as text and never evaluates submitted code.
A production Vault would process a task in an environment that controls the source and enforces its access policy. That environment would need authoritative permission, expiry, revocation and budget checks. Browser state cannot stand in for those services.
Declarations and guarantees
A Manifest can declare that execution has no network access or persistent memory. A JSON flag alone cannot establish either guarantee. The private execution adapter must implement the restriction and provide any evidence that the application intends callers to trust.
Similarly, a SHA-256 integrity check does not become a TEE attestation or zero knowledge proof. It checks content agreement within its declared scope.
Build from a complete path
Start with a sample Cell, open its configuration in the Console, change the request and inspect the outcome. Compile the policy, verify the record and try a failure branch.
The sample provides a concrete contract for a future execution adapter. Keeping its limits explicit makes that contract easier to test, rather than hiding the integration behind an invented success state.