Governed AI
How systems act within policy, approval, and scope instead of relying on vague autonomy claims.
WitnessOps Library
Public entry points for review, verification, docs, and current artifact classes.
Use this page to start in the right place: inspect verifier fixtures, published first-party proof bundles, explanatory sample cases, the illustrative sample report, package one proof-backed security workflow, and use docs for the model and trust boundaries.
No live customer proof artifact is linked from this index. Published bundles on /verify are first-party WitnessOps proof bundles unless a page explicitly labels them otherwise. Each artifact class below names its status, mechanism, and boundary.
What you can inspect here
WitnessOps public surfaces include product docs, verifier fixtures, published first-party proof bundles, explanatory sample cases, one illustrative sample report, the live review request lane, and receipt verification.
Docs cover the product contract. Review and verify cover the operational surfaces that are currently live. Sample surfaces stay explicitly non-live, while published first-party bundles are bounded WitnessOps-owned proof artifacts with their own declared limits.
Artifact state matrix
These are the public classes currently exposed here. Each one has a different authority, status, mechanism, and claim boundary.
Verifier fixtures
- Status
- sample fixture
- Mechanism
- Receipt JSON examples loaded into the receipt-first verifier to show clean pass, named failure, malformed input, and fail-closed behavior.
- Boundary
- Fixtures are not live customer artifacts and do not prove a production workflow or bundle completeness.
Open verifier
Published first-party proof bundles
- Status
- published first-party bundle
- Mechanism
- Downloadable ZIP bundles on /verify with receipt, manifest hash, source artifacts, and verifier-facing instructions for bounded WitnessOps-owned statements.
- Boundary
- These are first-party WitnessOps proof bundles, not live customer proof artifacts or customer assurance claims unless explicitly labeled otherwise.
Open published bundles
AI-agent sample proof run
- Status
- public sample bundle
- Mechanism
- A stable public sample with action boundary, authority map, evidence manifest, receipt, verifier result, challenge path, and MANIFEST.sha256.
- Boundary
- The sample demonstrates receipt shape and verifier path only. It is not production deployment, legal compliance, or complete AI governance coverage.
Open AI-agent sample
Explanatory sample cases
- Status
- explanatory workflow class
- Mechanism
- Named workflow-class pages with stable routes, authority maps, evidence expectations, and trust-dependent gaps.
- Boundary
- Sample cases explain shape and reasoning. They do not claim live customer evidence or production proof.
Browse sample cases
Illustrative sample report
- Status
- illustrative dossier
- Mechanism
- A generic dossier that shows review structure and judgment style.
- Boundary
- It is not a live customer report, verifier-of-record result, legal audit opinion, or compliance certification.
Open sample report
Live review request lane
- Status
- intake surface
- Mechanism
- Mailbox verification plus scoped follow-up for one real GitHub, Codex, AI, access, offsec, or remediation workflow.
- Boundary
- Submitting the form does not start a proof run and does not accept customer evidence until scope and handling are agreed.
Package Security Workflow
Published themes
Trust boundaries
Where control actually sits, what is delegated, what is assumed, and where misunderstanding begins.
Verification
How outputs, signatures, receipts, and evidence can be checked independently.
Failure modes
What breaks under pressure, what degrades, and what recovery looks like when the clean path no longer applies.
Architecture under scrutiny
How system claims read when customers, auditors, operators, or counterparties examine them closely.
Why this matters
Systems are easy to overclaim when the boundary is vague, the failure path is hand-waved, or the proof only makes sense inside the system that produced it.
A system becomes easier to trust when it can state:
- what it controls
- what it delegates
- what it assumes
- what can be checked independently
- what happens when normal operation breaks down
That is the level this site is concerned with. Not whether something looks advanced. Whether it remains legible under scrutiny.
Start here
Start by verifying receipts and bundles, then browse explanatory sample cases, package one proof-backed security workflow, and use docs for deeper model context.
Recommended first stop
Verify receipts and bundles
Use the public verifier to inspect sample receipts and any published first-party proof bundles listed on /verify.
Browse named sample cases
Inspect published sample cases for specific workflow classes with stable routes.
Review the lane
See the bounded review surface and what a review covers.
See a sample report
Inspect the sample report shape before submitting one real workflow.
Package a Security Workflow
Send one GitHub, Codex, AI, access, offsec, or remediation workflow for package scoping.
Decision surface
If this looks close to what you are building, move from reading to a boundary check.
Package Security Workflow →