Coverage Gaps and Non-Claims

This document is part of the honesty contract for Mandate Companion and Receipted Memory. A verifier can only check the signed evidence it receives. It must not turn missing or out-of-bound evidence into a green result.

Shared limits

• **No confidentiality guarantee.** Providers, websites, browser APIs, extensions, local malware, screen capture, logs, or the user can observe data once it is displayed, inserted, uploaded, pasted, exported, or sent.
• **No remote trust service.** Verification is local and offline. It does not fetch missing records or ask a Flow Memory service to decide trust.
• **Unanchored time.** Local `issued_at`, `signed_at`, and similar fields are client-asserted. The current release docs do not claim a trusted timestamping service; absent or null anchor fields mean time-unanchored evidence, not trusted time.
• **Local wipe and tail-truncation detectability limits.** Verifiers can detect malformed supplied chains, sequence gaps inside supplied chains, and previous-hash mismatches. They cannot prove that the user did not delete the whole local database, withhold an entire export, or omit a valid tail after the last supplied record unless the reviewer already has an earlier trusted head, count, or last hash to compare.
• **Browser support.** The current extension target is Chromium MV3, specifically Chrome and Edge. Firefox, Safari, mobile browsers, hardened enterprise builds, disabled WebCrypto, disabled IndexedDB, disabled extension storage, and policy-restricted optional host permissions are outside the supported path unless a release explicitly adds and verifies them.
• **Optional site permissions.** Host access is intentionally requested per supported site at runtime. If the user or browser policy declines optional permissions, page integration may not run. A lack of permission is not a verifier failure; it is a runtime coverage limit.
• **Third-party review still required.** Local tests and fixtures do not replace external security review, Web Store review, or user review of prompts and exports.

Mandate Companion gaps

• **Executor boundary only.** Mandate Companion gates and receipts supported actions routed through its executor. It is not a browser sandbox and does not control arbitrary site JavaScript, browser chrome, native apps, other extensions, downloads after handoff, or provider-side behavior.
• **Effects outside the executor.** A verified receipt can show that a supported executor action was authorized and recorded. It cannot prove every downstream effect caused by the page, provider, network, server, browser autofill, or another extension.
• **In-page XHR and fetch.** The verifier does not observe or authorize arbitrary XHR, fetch, beacon, websocket, service-worker, or analytics calls made by the page itself. A click or form fill may trigger site network behavior outside the signed action model.
• **Closed shadow DOM.** Closed shadow roots and browser-private controls are not inspectable by the generic DOM snapshotter. Missing closed-shadow evidence must be treated as a coverage gap, not as proof that no relevant UI existed.
• **Cross-origin iframes and payment frames.** Cross-origin payment iframes and embedded provider frames are not inspectable or controllable as same-origin DOM. Payment submission, wallet popups, bank challenges, and card-entry iframes are outside the Phase 1 executor boundary unless a release adds a verified site-specific integration.
• **CAPTCHAs and anti-bot UI.** CAPTCHA, risk-review, identity, and anti-bot flows may block automation or require manual handling. Receipts do not prove those flows were solved or bypassed.
• **BYO provider data visibility.** In BYO OpenAI or Anthropic mode, the selected provider receives the API request needed for the run, including goal text, mandate wording, page snapshot, step history, proposed action data, and the API key for that request. The extension cannot make those provider calls confidential from the provider.
• **Redacted export gaps.** Redacted bundle exports intentionally remove sensitive payloads. If a scope decision depends on omitted payload evidence, a verifier must report `gap` rather than `within_scope`.
• **Revocation is detection evidence.** Signed revocations let an offline verifier detect later inconsistent receipts. They are not a remote kill switch for compromised code or a browser profile the user no longer controls.
• **Checkpoint/export limits.** Mandate Companion may keep signed local head pointers, but reviewers can rely only on checkpoint or head evidence that is actually included in the reviewed export and understood by the verifier version they are using.
• **Key rotation continuity.** A new signing key is not silently equivalent to the old key. Reviewers should require signed continuity evidence or an out-of-band trusted key transition before treating receipts under a new key as the same custody chain.

Receipted Memory gaps

• **Released values are provider-visible.** Receipted Memory records what the local client prepared and signed. Values selected by the user are inserted into Claude or ChatGPT and become visible to that provider when the user sends the prompt.
• **Plaintext exists during release.** The extension decrypts selected fields locally to prepare the prompt. Non-extractable keys reduce key export risk; they do not stop trusted running extension code, the page after insertion, or a malicious future build from seeing plaintext while it is present.
• **Manual send boundary.** The extension prepares the prompt; the user manually sends it. The verifier does not prove what happened after manual send, how the provider processed it, or whether the user edited the composer before sending.
• **Site-specific DOM limits.** Claude and ChatGPT UI changes, closed shadow DOM, cross-origin embedded controls, browser autocomplete, experimental UI variants, and anti-automation changes can prevent reliable detection or insertion.
• **In-page XHR and page scripts.** Provider pages may make their own network requests and run scripts outside Receipted Memory's receipt model. A receipt does not enumerate those calls.
• **Withheld-field limits.** Receipts can include withheld field ids for minimization review, but withheld values are not intentionally exported. The verifier cannot infer the content of withheld fields.
• **Local wipe and truncation.** The JSONL chain verifier checks the supplied lines. It cannot prove that earlier or later local receipts were not deleted or withheld unless the reviewer has a prior trusted chain head, count, or last hash for comparison.
• **Unanchored time.** `issued_at` is client asserted. The current release docs do not claim a trusted timestamping service; absent external timestamp evidence means time-unanchored evidence.
• **Recovery limits.** Local recovery sheets are user-held backup material only. Flow Memory cannot reconstruct a lost vault, passphrase, recovery code, signing key, receipt log, or compliance ZIP.

What reviewers should ask for

• The exact extension package or store version under review.
• The verifier package or static verifier shipped with that version.
• Mandate Companion: the complete redacted `mandate-bundle/1` export and any prior trusted head/count/last-hash evidence if tail-truncation detection matters.
• Receipted Memory: the complete compliance ZIP, including `receipts.jsonl`, `public_key.txt`, `README.txt`, and `verifier.html`, plus any prior trusted chain head/count/last-hash evidence if tail-truncation detection matters.
• An out-of-band trusted public key or signed key-continuity record for custody claims.
• Explicit acknowledgement that unanchored timestamps are not trusted time.
• External security-review report and Web Store review status before public launch claims are made.