How ControlFrame decides a control is satisfied
Not a black box and not a vote of confidence in a model. A declared contract, source-bound collection, a suggestion an agent is never allowed to finalize, a decision a named person makes, and a record either of them can be checked against later.
The decision chain
Nine steps, each one a real mechanism elsewhere in the product — not a diagram drawn for this page. An evidence contract at the start and an offline verifier at the end; a human decision in the middle that nothing upstream or downstream can substitute for.
An evidence contract is declared first
Scope, source system, expected proof, and a freshness policy are written down before collection starts. Nothing is collected against an undeclared expectation.
Collection is source-bound
A browser, API, or document collector runs inside the configured customer or operator boundary and records exactly where each artifact came from — never a screenshot reconstructed after the fact.
Every artifact is validated on arrival
Checksum, format, and freshness are checked against the contract before an artifact is eligible for review. A collection that fails validation is flagged, not silently accepted.
An agent may suggest a control mapping — and only suggest it
A governed agent can propose which control an artifact appears to satisfy, across one framework or several. It records that suggestion with its reasoning. It does not mark a control satisfied.
A named reviewer performs sufficiency review
A person evaluates the artifact against the control's actual criteria — not the agent's suggestion — and accepts, rejects, or conditions it. This is the decision the method is built around: it belongs to a person, every time.
The decision is sealed into a hash-linked custody chain
Every act against an artifact — captured, scanned, redacted — is appended to an ordered record naming the digest it acted on. The chain shows exactly which bytes were reviewed, and whether a later act changed them.
A package is assembled with its own manifest
A release candidate carries its source coverage, checksums, redaction record, and reviewer decisions with it — the package proves its own history instead of asking an auditor to trust a dashboard.
Release requires a human authorization
A package cannot leave the system on an agent's own decision. Export and external release fail closed at a named person, the same way acceptance, exception, and signature do.
The result is independently verifiable, offline
An eligible export carries a Governed Receipt (governed-receipt/v1): an Ed25519-signed, hash-linked statement a recipient can re-verify in a browser with no ControlFrame server in the trust path, at the shared Locked In Labs verifier.
What a model may propose. What a named person must decide.
The left column is where agentic speed lives. The right column is where accountability stays, regardless of how good the model behind the left column gets.
| A model may propose | A named person must decide |
|---|---|
| Suggest which control an artifact appears to satisfy, across one or more frameworks. | Accept, reject, or condition that mapping against the control's actual criteria. |
| Flag an artifact as stale, incomplete, or inconsistent with its declared scope. | Grant an exception, require re-collection, or escalate the finding. |
| Draft a package candidate with its manifest, checksums, and redaction summary. | Authorize the package for release to an auditor or external party. |
| Summarize evidence, prior decisions, and open gaps for a reviewer. | Sign the conclusion the summary supports. |
Questions this page answers
How does ControlFrame decide a control is satisfied?
It doesn't, on its own. A governed agent can suggest which control an artifact appears to satisfy; a named human reviewer evaluates that suggestion against the control's actual criteria and accepts, rejects, or conditions it. The decision is a person's, recorded as theirs.
What stops an agent from approving its own collection?
The gate is structural, not a policy on paper: acceptance, exception, sufficiency review, signature, and package release are actions a governed agent cannot complete by itself in the product. Each one requires a distinct human action.
What proves an artifact wasn't altered after it was reviewed?
Every act against an artifact — captured, scanned, redacted — is appended to a hash-linked custody chain naming the digest it acted on. A break in that chain, or an act naming bytes other than the ones reviewed, is visible rather than assumed away.
Can someone outside ControlFrame check this without trusting the product?
An eligible export carries a Governed Receipt (governed-receipt/v1). A recipient can paste it into the shared Locked In Labs public verifier and recompute the hash chain and Ed25519 signature themselves, in their own browser, with no ControlFrame server in the trust path.