OSuite / Solutions / Evidence note 01
Versioned, author-run evidence for document, change and batch-operation controls, with complete comparators and the deployment conditions kept visible.
13 November 2026 / Toronto, Ontario, Canada / Controlled evaluation, not a customer production deployment
Installed path, disclosed resource
A fresh Studio/PostgreSQL installation, released osuite@2.13.0, original OPA 1.22.4 and a separate synthetic HTTP/SQLite resource. The main matrix contains 24 fixed scenarios, three variants and four configurations. Reviewers were scripted; no bank, retail customer or production system participated.
| Configuration | Sequences | Normal tasks | Unsafe effects | Repeat effects, same ID | Public reads |
|---|---|---|---|---|---|
| Policy precheck + ordinary resource | 72 | 9/9 | 27 | 15 | 3 |
| Precheck + released SDK + ordinary resource | 72 | 9/9 | 27 | 0 | 3 |
| Conventional journal + protected resource | 72 | 9/9 | 0 | 0 | 0 |
| Released SDK + the same protected resource | 72 | 9/9 | 0 | 0 | 0 |
Every configuration has 72 sequences and nine normal two-item tasks. Effects can overlap; counts are not incident frequencies, attack-detection rates or estimates of customer risk reduction. Denied, partial and unknown outcomes remain in the exception cases.
What happened at the resource
In one scenario with three variants, a client actually read synthetic content after visibility changed to public. A later private correction removed public access but did not erase the saved read. Both ordinary-resource configurations exposed content; both protected-resource configurations rejected the mutation.
This was a real unauthenticated loopback HTTP read, not a live document tenant or an Internet exposure test.
The harness destroyed a socket after resource commit and killed caller processes before send or after commitment. In 18 journal-protected local crash cases, the same operation was re-offered after reopening the journal: 12 SDK attempts and six conventional-journal attempts. Retained harness records show no additional parent-process callback or extra resource effect on those re-offers; original child callback execution is counted separately.
Callback counts are recorded harness observations, corroborated by saved-record review, not independent attestation by the Python integrity checker. Its callback-marker scan does not validate all structured child evidence. When lookup was unavailable, controller knowledge remained unknown even if an offline assessor could see the committed row. New-ID repeats still needed resource-side business uniqueness.
The SDK/protected-resource configuration recorded 33 completed callbacks with denied, business_duplicate or business_declined business returns. The conventional journal uses the same lifecycle convention. This is not a broken promise of bank success by the SDK; it is a required integration distinction.
Keep callback lifecycle, per-item resource state and whole-task status separate. The experiment supplies independent interpretation; it does not establish a deployed business-result view.
A separate mechanism study
The known-family Ambit replication produced 936 records and 1,872 JavaScript/Python receiver outputs, with zero false supported claims or role regressions. Four original-component invocations and twelve original capture replays underpin the records; the row count is not a count of native workflows.
| Method | Definitive supported | Explicit unknown | Unsupported |
|---|---|---|---|
| Complete point-to-point | 119 | 37 | 156 |
| Generic intermediate representation | 119 | 37 | 156 |
| Ambit | 119 | 37 | 156 |
Supporting resource-contract replication
A dedicated Canada Central Standard_D4as_v5 CPU VM reproduced 144 two-configuration policy/resource sequences. The policy-only control retained 27 unsafe effects; the protected conventional resource retained zero. A separate test issued 1,152 offers for 576 unique operations at 1, 8 and 32 in-flight requests, with three waves per level. It recorded no duplicate or over-budget resource effects.
After all responses, the resource process was killed and restarted; nine stored cases retained their effects and checked lookup results. Evidence was downloaded and independently recomputed before the dedicated resource group was deleted.
Where the next evidence must come from
| Area | What must be established |
|---|---|
| Provider integration | Actual ACL inheritance, content/version changes, native write conditions and per-item readback on the chosen document or business platform. |
| Product delivery | A supported install-to-recovery path and user-visible business results, without hand-wiring research modules. |
| Authority and durability | Real credential/approval expiry, restore behavior and the precise boundary between final checks and independent resource commits. |
| Economics and user value | Comparable full costs, maintenance tasks, operator recovery and an authorized design-partner evaluation. |
Public aggregate, not raw sessions
Download the result table, structured evidence record and reusable acceptance worksheet. These files contain no customer data, raw sessions or credentials. Retained report hashes identify source records; they are not external certification or a substitute for a full reproducibility package.
5,019 bytes
SHA-256 2d10deae1865b2483405502860c6574ab20942e17353f33526a996ca48b89564228 bytes
SHA-256 fd4f098e8b5eea186652f0b7d4ca59600fd4870a2ccf15ec4c0fefc55dc6d89d2,634 bytes
SHA-256 bf79196d5756d5447e9b803f29197f33cde843e387a2989220060a8f68f8bb43Machine-readable download manifest. A separately reviewed raw-evidence subset can be scoped for technical diligence. Earlier experiments remain separate; their denominators are not pooled here.
Public implementation and operating context
Operational change, testing and recovery context; not compliance certification.
Link defaults, reuse and permission behavior require provider-specific qualification.
Direct and inherited permissions are not interchangeable.
An envelope response is not evidence that every individual request completed.
Native idempotency has an explicit contract; it is not replaced by generic retry handling.
These references inform scenario design. They do not imply vendor endorsement, adoption, compliance or a completed integration.
Start with one boundary
Select one task, its actual tools and the decision owner. We can assess whether existing controls are sufficient, whether a narrow adapter is useful, or whether a broader integration deserves a pilot.
Pilot scope, prerequisites and commercial terms are agreed separately. No production access is needed for the initial discussion.