Browser-local evaluation
Run synthetic support or IAM tasks through deterministic policy logic. Bind the configuration, inspect the verdict, and download the evidence.
Trust & controls
Evidence you can inspect. Limits you can see.
A useful reference check starts with a clear boundary. Origin evaluates a bound configuration against deterministic synthetic tasks and gives reviewers an artifact they can recheck.
Working prototype. Seeking design partners. Not production SaaS or compliance certification. Not a guarantee of approval.
01 / Current posture
What exists today. What still needs agreement.
The public prototype demonstrates an evaluation and evidence workflow. A runtime gate and controlled tool-call proxy remain proposed pilot architecture, not deployed general enforcement.
Explicit artifact provenance
The public reference-check artifact is browser-session-signed and unpinned. Execution was not attempted. A valid signature does not establish trusted Origin issuance.
Controlled execution
Permission checks, a controlled proxy, named approvals, and runtime enforcement are a proposed integration path. They are not evidence of a customer deployment.
02 / Verification
The checks have a record, too.
The deterministic oracle is the sole label and reward authority. make gates-all runs the public repository's build, tests, evidence checks, and honesty checks. Inspect the CI definition or reproduce the checks locally.
Reproduce locally with
make gates-all. The gate snapshot shipped with this release loads here (needs JavaScript).A timestamped snapshot is evidence of that run, not a live assurance. Numbers in this scoreboard are reproducible under this verifier on the public repository. Private research metrics published elsewhere have separate provenance.
03 / Data & retention
Different workflows. Different data boundaries.
The public reference check, a contact request, and an authorized pilot are different activities. Their data handling should not be conflated.
| Workflow | Data boundary | Retention posture |
|---|---|---|
| Synthetic reference check | Browser-local policy evaluation and downloadable demo artifacts. No production action is attempted. | Public evaluation does not require submitting customer traces or credentials. |
| Contact request | Information you choose to provide when requesting a review. There are no customer accounts; the console is owner-only. | Contact deletion can be requested. Account and service handling are described in the privacy policy. |
| Foundry image processing | The public site offers a local sample. An enabled local/backend demo requires affirmative consent before an image is sent to Cerebras. | The Origin handler does not intentionally persist the image; provider terms and retention apply. See the processing disclosure. |
| Separately authorized pilot | Evidence, permissions, redaction, and data-use scope must be agreed before customer material is used. | Retention, deletion, and deployment-specific controls are not finalized; settle them in the pilot agreement and DPA. |
04 / Responsibility
Verification informs a decision. It does not take ownership of it.
Capability is not permission. The customer retains responsibility for its systems, agent deployment, business decisions, and release authority.
Deterministic authority
The verifier evaluates the bound checks. Model output does not grade itself. A failed integrity or configuration check invalidates the relevant artifact.
Check the artifact type
Supported artifacts carry different bindings, signatures, digests, chains, or inclusion proofs. The verifier reports the checks and limitations of the artifact you provide. You can exercise each mechanism in the verification workbench and compare held with exercised authority in the over-grant analyzer.
A named owner decides
A demo result does not grant production access. Integration design, access controls, incident ownership, and residual risk need separate review and agreement.
05 / Security review
Start with the questions your reviewer needs answered.
A founder-led review can scope a security packet for one workflow. Origin does not claim SOC 2, ISO, or any compliance certification.
| Item | Status | What to confirm |
|---|---|---|
| Data Processing Agreement | Not finalized | Data scope, permitted uses, retention, and deletion for the engagement. |
| Subprocessors | By request | The infrastructure and providers relevant to the proposed workflow. |
| Security checklist | By request | Current prototype controls and the integration work still required. |
| Incident ownership | Pilot-specific | Named contacts, escalation, and deployment-specific responsibilities. |
Bring one workflow. Start with its boundary.
Discuss the configuration, the approval blocker, and the evidence a reviewer would need.