Run governed Driver App evidence safely
Driver App does not currently include an accepted documentation-capture harness, trusted runner, or trusted runner key. The documentation verifier and schemas validate evidence structure and fail-closed dispositions; they do not make an App launch, simulator, provider, or backend safe.
This is a responsibility contract. Runtime remains source-api-only, and media
remains deferred until every promotion gate is independently accepted.
Availability
Static source-safe evidence is available from accepted source objects, tests, schemas, inventories, and independently reviewed dispositions. Behavioral or visual runtime evidence is unavailable by default.
No executable capture command, shared-runtime lease, behavioral output, or media output is admitted in the current contract.
Prerequisites
Before any future capture is considered, establish all of the following:
- Exact immutable App, Components, and API research authority with independent review.
- A purpose-built synthetic fixture containing no real account, order, message, location, media, token, or operational identifier.
- A serial Runtime Steward lease for one exact scenario and command.
- Network, socket, push, GPS, map, camera, photo, document, signature, contact, clipboard, print, storage, and provider adapters that fail closed.
- Zero allowed real effects and an explicit list of expected local outputs.
- Before/after effect counters, egress evidence, cleanup receipt, and an independent reviewer who did not author the fixture or article.
If any prerequisite is absent, remain source-only and keep media deferred.
Responsibility boundaries
| Owner | Responsibility |
|---|---|
| Documentation author | Define the claim, synthetic state, expected observation, denied effects, and maintenance trigger |
| Fixture owner | Provide typed, finite, non-sensitive local inputs with no implicit provider fallback |
| Runtime Steward | Hold the sole serial lease, admit one reviewed command, monitor effects, and stop on drift |
| App/provider adapters | Prevent unknown egress and real native/provider actions |
| Evidence reviewer | Verify exact scenario binding, privacy, effect counters, outputs, and cleanup independently |
| Publication owner | Integrate only accepted claims/media and keep private evidence out of public docs |
A simulator is a device runtime, not a hermetic boundary. Mocked UI alone is also insufficient when an imported component can mount a provider or effect.
Inputs and result
A future admitted scenario must bind:
- One article and one claimed state.
- One exact synthetic fixture revision.
- One exact source revision set and platform/build identity.
- One command, working directory, adapter set, and output allowlist.
- Zero real-effect budget and zero unknown-egress budget.
- Expected assertions, log privacy rules, timeout, cleanup, and independent verdict.
The result is not “the app opened.” It is a bounded receipt proving that the expected synthetic state was observed, no denied effect occurred, no unknown egress occurred, only allowlisted outputs were produced, cleanup completed, and the independent reviewer accepted the evidence.
Security and privacy
Never use real credentials, sessions, people, phone/email, orders, assignments, addresses, coordinates, messages, read receipts, media, signatures, PINs, payment data, provider identifiers, or production-like secrets.
Never permit real order/status/assignment, availability, location, message, contact, notification, session, review, account, media, print, or provider effects. Redact private repository paths, API details, tokens, internal finding details, and operational logs from public artifacts.
Limits and failure states
| Condition | Required result |
|---|---|
| No trusted App harness or runner | Stay source-only |
| Unknown network/native/provider behavior | Fail closed before launch |
| Shared runtime already leased | Wait; never run concurrently |
| Fixture uses real or ambiguous data | Reject the fixture |
| Output not allowlisted | Stop, quarantine, and reject evidence |
| Effect counter changes | Stop and treat as a real-effect incident |
| Cleanup missing or partial | Reject the entire run |
| Source/config/build drift | Invalidate the scenario and rereview |
| Deployment relationship unresolved | Exclude deployed-behavior and success claims |
Static tests and verifier success can certify contract structure. They cannot promote a source-only scenario to behavioral acceptance.
Troubleshooting
A simulator is available
Do not launch it for documentation evidence. First prove every adapter, egress rule, effect counter, fixture, output, cleanup, and Steward requirement.
Existing tests render the screen
Use them as supporting source evidence only unless the complete runtime receipt contract is satisfied. A mocked render can omit productive imports and effects.
A screenshot looks synthetic and harmless
Appearance is not isolation. Reject it if its provenance, exact fixture, provider denial, effect counters, output allowlist, or cleanup receipt is missing.
Capture needs a real provider or account
Do not capture it. Keep the visual plan deferred and document the provider-owned state textually until a zero-egress synthetic substitute is accepted.
A future harness is added
Treat it as untrusted until independent review proves exact source/build binding, strict fixture schemas, deny-by-default adapters, zero effects/egress, output containment, cleanup, adversarial tests, and serial Steward control.
Related guides: Driver App architecture · Authenticated bootstrap · Use the reviewed communication contract · Driver App overview