Earlier work, kept for reference.
Not part of the current products. These tools and reference pages belong to the finance work that came before the client review. Each one says how far along it got and whether it runs on a sample or on your own files. The invoice examples are on the demo page.
Specialist tools
The same checks applied to other jobs, mostly in finance.
- Govern an actionEarly accessInteractive sampleOne action against a standard, before it runs and after, with every control: the recipient, the scenario, the readback, your own standard.
- Compare two recordsAvailable nowUse with your filesTwo reports, one published template, counts and commitments; export a result the other side confirms against its own copy.
- Write a standardEarly accessUse with your own termsState the decision you own, the limits, the evidence, and the consequence from supported requirements; read it back in plain English, confirm, and sign in your browser.
- Record a decisionAvailable nowInteractive sampleReview one checked Case and record accept, reject, or request inspection, signed.
- Connect a sourceAvailable nowUse with your filesDescribe a CSV export, an API, or a signed file delivery once, so proofs carry the source's own confirmation.
Worked examples
On sample data and demo keys, for anyone who wants to see a whole Case before setting a standard of their own.
- A three-party CaseAvailable nowCase studyA recipient asks, an operator answers locally, a source owner confirms, the recipient decides.
The earlier reference pages
The security pack, the threat model, the control register and the regulatory mapping written for the finance products, kept as they were. For the current products, read Security and How it works.
Where each control is checkedTechnical reference: policy, receipts, receivers and human decisions.
This matrix describes controls across supported workflows. A run must supply the relevant policy, receipts, receiver evidence or attestation; these controls are not all implied by using a hosted room or installing a gateway.
| Control | Where | When | Who can recompute it |
|---|---|---|---|
| Which tools, by exact name | The gate | Before the call runs | Anyone: the policy and its digest are in the record |
| Rules over time (no B after A, at most N in a window, A before B) | The history of calls | At every receipt | Anyone holding the receipts, with the receipt where a rule broke named |
| Amounts and approvals | The records, and the service's receiver where one runs | After the work, and at the moment of spend | The verifier, from the decisions and readbacks |
| The network rule | The environment | Attested with the run | Anyone reading the attestation; the gate sees calls, not packets |
| Sentences no control can check | A named person | Before the work is relied on | Recorded with who judged them and when |
Enterprise security packData boundaries, customer ownership, engagement artifacts, and the audit-bundle shape.
Use this pack to review a configured local gateway and its enabled services. Local evaluation, hosted collaboration, optional model assistance and evidence sharing have different data paths. The controls must be checked against the installed version and the routes your agents actually use.
Read the security packthe whole document, on this page; the download is the same text
ScopeBlind Enterprise Security Pack
Deployment scope
The configured local gateway evaluates supported agent tool calls and signs receipts in the customer environment. Credential isolation, approval support and route coverage depend on the installed version and configuration. This pack is deployment guidance, not certification of an installation.
Hosted services are a separate data path
The shared invoice service stores names, agreements, sample records, actions and results, and operates a sandbox gate and ledger. Guided requests are scripted. Live-agent jobs send the brief and sample records to the model provider; optional rehearsal readback sends the supplied text and sample invoice context. An agent you connect may send room data to its own provider. Browser participant signing keys stay in their browsers; the service holds separate operator signing keys.
Optional model assistance on Write sends the conversation, current readback and tool context through ScopeBlind to the configured model provider. Publishing a standard, syncing receipts and creating hosted shares send the selected content to ScopeBlind. Contact details and setup context submitted through the enquiry form are held for up to 120 days.
Configured local data flow
- Review a mandate and the installed policy.
- Route supported agent actions through the local gateway.
- The gateway evaluates each routed action before the tool runs.
- The installed policy and approval path determine whether it allows, holds or denies the action.
- The gateway signs decision receipts locally.
- Export an audit bundle or enable a documented reporting path when needed.
Local data boundaries
- Local evaluation and local verification do not require sending raw positions, research, prompts or private keys to ScopeBlind.
- Your agent's model provider and destination tools have their own data paths. Review them separately.
- Inspect exported and reported fields: some records disclose actions, inputs and decisions; a position-blind adherence pack carries selected digests and counts.
- Support logs are shared when the customer supplies them. Do not include private keys, tokens or credentials.
- If feature-flagged closed-Case billing is enabled, account metadata and one idempotent credit record can be reported; local receipts are not metered by that mechanism.
Threat model summary
- Insider mandate edits: compare committed mandate digests and signed receipts against the authority you accepted.
- Network attacker: signatures detect edits to signed fields; an attacker can still delay, drop or replay evidence. Check freshness.
- Verifier compromise: verify with a trusted local verifier or on multiple devices.
- Selective disclosure: sequence checks, retained receipt heads and administrator or custodian reconciliation strengthen coverage where integrated.
- Key compromise: a valid signature does not establish safe custody. Pin expected keys and review the configured custody and revocation controls.
Acceptance criteria for an engagement
- Install and identify the gateway version.
- Load a sample or customer-approved read-only book.
- Review and commit one mandate and its policy.
- Run one governed action and confirm the configured route is active.
- Hold one consequential action for the configured approval path.
- Export one audit bundle and verify one receipt offline.
- Check which tools and destinations remain outside the governed route.
Explicit non-claims
- The hosted invoice trial uses fictional invoices and simulated funds, not a bank or live trading system.
- A hosted rehearsal report covers its included test cases, not another deployment or every possible input.
- ScopeBlind does not sit on a live FIX/OMS order path unless separately integrated.
- A signature establishes signed bytes and key possession, not economic truth or independent observation.
- A single pack does not prove completeness without sufficient sequence, coverage and reconciliation evidence.
Local evaluation covers routed calls. Review model, tool and reporting paths separately.
Keep the receipts and expected keys for the configured workflow; verification can run locally.
Billing can count closed point-in-time Cases without counting local receipts or receiving activity payloads.
| Surface | Default disposition | Plain-English boundary |
|---|---|---|
| Local gateway inputs | Configured locally | Local evaluation does not require raw inputs to be sent to ScopeBlind. Model providers, destination tools and enabled reporting have separate data paths. |
| Hosted shared jobs and rehearsals | Service state | Names, agreements, sample records, actions and results are stored by ScopeBlind. Live work and optional readback use a model provider. |
| Contact details you submit | Sent on submit | The work email and setup context entered in the enquiry form go to ScopeBlind and are kept for up to 120 days. Shared rooms separately store the names participants provide. |
| Proof Request drafts | Browser draft | The Proof Request editor saves its draft in your browser. Exporting or sharing discloses the selected content. Write model assistance and hosted standard publishing are separate network actions. |
| Standards and receipts | Workflow-dependent | The local gateway signs receipts locally. Hosted rooms store their evidence on the service. Published standard pages and optional reporting also use the service. |
| Billing signal | If enabled | The closed-Case billing mechanism records one idempotent credit for a closed point-in-time Case. It does not meter local receipts. |
| Support artifacts | Explicit share | Logs, screenshots, packs and configs become support material when you send them. Remove credentials and private keys first. |
An engagement should end with a customer-owned folder that can be reviewed offline without calling ScopeBlind.
audit-bundle/ mandate.digest.txt receipts/decisions.jsonl approvals/phone-or-desktop.jsonl evidence/position-blind-pack.json exports/booking-ticket.csv verify.sh README.md
Verify a pack in this browserPaste a signed pack or load the canonical sample. Nothing is uploaded.
Paste a signed adherence pack a desk produced, or load the canonical sample. It is verified here, in your browser, offline: the canonical digest is recomputed and the Ed25519 signature is checked against the runtime key the pack carries. Nothing is sent anywhere. Positions are never in an adherence pack, so you verify adherence without seeing the book.
How it behaves at the edges
Failure postureThe hosted payment route and local reference controls have explicit limits.
Source assuranceWho controlled the evidence source, how it arrived, and what that still does not prove.
Source assurance is not a numeric trust score. The product records who controlled the evidence, how it arrived, and whether another party signed it. Coverage, freshness, recipient trust, and acceptance are evaluated separately. The hosted invoice trial is intended for fictional sample data; a model readback does not authenticate its source. Higher-assurance paths require an appropriate source integration.
Threat modelInsiders, transport, compromised verifiers, missing records and stale evidence.
Each row names a threat and the headline mitigation. Open one for the full reasoning.
Insider threatThe mandate digest is shared or published before the period, so later deviation is detectable.
An operator could modify their local mandate or snapshot. Mitigation: the mandate digest is shared with allocators (or published) before the period begins, so any later deviation is detectable.
Network adversaryHTTPS protects hosted transport; signatures detect changes to signed fields. Check freshness and missing evidence too.
Hosted requests use HTTPS. Local transport depends on the deployment. Signatures make changes to signed fields detectable but do not stop delay, omission or replay. The browser-local examples evaluate in-process; hosted rooms use a service.
Verifier compromiseVerify on multiple devices, or run the open verifier locally.
The offline verifier is stateless JavaScript. An attacker who controls the browser the allocator is using could show a fake "valid" result. Mitigation: verify on multiple devices, or run the open verifier locally.
Selective disclosureAdministrator reconciliation and sequence checks strengthen period coverage where integrated.
An operator can withhold packs or act outside the governed route. Administrator reconciliation and visible sequence gaps can strengthen period coverage where integrated; neither replaces an explicit deployment coverage check.
Stale evidencePacks bind a stated period and a signed issued_at; check the dates against your diligence window.
An old pack can be re-presented as current. Mitigation: packs bind a stated period and signed issued_at; check the dates against the period you are diligencing.
History rewriteDetectable to anyone who retained an earlier head and checks the consistency proof against it.
An operator could trim or rewrite an earlier record. This is not caught by any single pack; it is detectable to anyone who retained an earlier head and checks the consistency proof against it.
Advanced · Filed assurance mechanismsTwo bounded capabilities, available to design partners: test the declared evidence boundary, then couple supported completion to required evidence.
These mechanisms extend a point-in-time Assurance Case. They do not create standing assurance, universal route coverage, or trust by themselves. The recipient still decides which inventory, observations, sources, and keys are acceptable.
Could a relevant event have escaped the declared evidence boundary?Claim-directed closure and detectability · Design partner · simulator-tested
What it establishes: a deterministic result over the routes, observation positions, exclusions, and trust domains bound into this Case. Unknown, uninspected, or bypass-capable routes remain visible and prevent an affirmative result when the recipient's policy requires closure.
What it does not establish: that no undiscovered route exists, or that anything outside the inventoried boundary was observed. Australian provisional application 2026906437 was filed on 20 July 2026; filing is not a patent grant.
Could a supported governed action finish without the required evidence?Evidence-coupled authorization · Early access · receiver-participating reference route
What it establishes: for the supported reference route, completion requires a one-time capability, the policy's witness acknowledgements, and a receiver-signed outcome. Replay, mutation, missing evidence, and a lapsed completion lease fail closed.
What it does not establish: atomic completion for an externally irreversible system that does not participate in the protocol. Australian provisional application 2026906436 was filed on 20 July 2026; filing is not a patent grant.
Machine-readable release scope, schemas, and the evidence-authorization conformance vector are published in the A/C conformance manifest.
Hosted shared invoice serviceGuided jobs, live agents and rules rehearsals use the service.
The service stores collaboration state, checks supported sandbox payments and records its outcomes. Guided jobs use scripted requests; live jobs use a model provider when available. Rules rehearsals exercise included cases in isolated service ledgers. Optional readback suggests a case; it does not change the rules or run a test.
Browser-local reference tools and additional integration paths are listed separately below. Their availability does not mean they are connected to a shared room.
Browser-local reference toolsPolicy examples, signatures, imports and verification.
Additional configured integrationsAvailability depends on the integration and deployment.
Compliance and audits
Control posture (SOC 2 criteria)The SOC 2 Trust Services Criteria, mapped to live controls.
We will not claim a certification we do not hold. This is the control posture: what a buyer can verify today, what is in progress, and what is on the roadmap to a SOC 2 examination, mapped to the Trust Services Criteria.
The instant-try demo is deliberately accountless and local. Authentication, SSO, RBAC, and a managed persistence layer are properties of the commercial product, not of this demo, and a live receipt or pack proves integrity without any of them.
Certifications and auditsCurrent audit status and published verification artifacts.
We will not claim certifications we do not hold, and there is no blockchain or token anywhere in this system; tamper-evidence comes from plain Ed25519 signatures over canonical bytesCanonical bytes: the receipt JSON re-serialized one deterministic way (keys sorted, no whitespace), so the same record always hashes identically. The signature is over these bytes, which is why any edit is detectable..
Regulatory control mappingHow the controls map to NIST, the EU AI Act, DORA, SEC, and MiFID II.
A control-and-evidence mapping, not a certification. Apply each row only where the named control is configured and its evidence is present. Hardware co-signing, source integrations and witnessed records are separate deployment capabilities, not guarantees of the hosted invoice trial. Regulatory sufficiency is the firm's compliance and legal determination.
Full mapping with per-control source references is maintained in docs/compliance-mapping.md.
Related assurance mechanismsDeployment-specific controls and their current availability.
These mechanisms belong to distinct evidence formats and deployment paths. Check the stated availability and integration before applying a claim to your own workflow:
- Enforcement on a configured route. The hosted payment gate checks supported requests before they run. Other gateways and integrations require their own coverage and activation checks.
- Position-blind adherence format. The specialist adherence pack shares selected digests, verdicts and counts. Other exports can disclose inputs and records; inspect their fields.
- Device-bound human co-sign (early access) on held actions, so a paired deployment can bind approval to a registered device rather than a generic checkbox.
- Signed input provenance (design partners), so a configured source adapter states where each input came from and how far a recipient should discount it.
A fifth property, issuer-blind verification (receipts checkable without revealing who issued them), is not being built: the managed issuance layer that was to carry it was withdrawn, and its redemption routes were retired on 5 October 2026. If it were ever needed, it would use the IETF Privacy Pass and ARC standards rather than a scheme of our own. This browser demo uses plain Ed25519, and the verifier is open.
Security questionnaires, data-flow diagrams, or a walkthrough for your team:Request the security questionnaire. Ready to start? See the plans.