Acceptance evidence: our published test results.

Current release — acceptance suite inside a bound capture

Method. The full acceptance suite was run on our lab host running signed release v0.6.0 (source commit 88490b6), inside a single 900-second packet capture bound to that same workload on the host’s boundary interface. Retrieval was exercised as an authenticated user through the HTTPS gateway rather than over loopback, and every evidence manifest was verified on the host and again on a separate machine.

Result. 31 checks passed, 0 failed, 0 not assessed. The capture recorded 10,530 packets to 33 destinations, with zero unapproved destinations, zero unparsed packet lines, zero kernel drops, and zero truncated packets; an independent decode of the capture matched the recorded destination inventory. The authenticated document Q&A run passed all eight of its checks, including the citation and the removal of the synthetic file and its vectors. Health sampling across the same 900 seconds recorded 31 samples, 0 failures, and 0 container restarts. The suite reports this as a lab result: delivery readiness is a separate result at a customer site, and this run does not claim it.

Verified 2026-09-08 · our own lab host, two consumer 12 GB RTX 3060 cards. That hardware is deliberately not a performance datapoint. This run qualifies the software, the boundary, and the controls—not throughput.

Current release — multi-user document isolation, including revocation

Method. Two ordinary non-administrator principals in separate groups. The owner uploads a private document containing a distinctive marker. Before any denial is trusted, a control step requires the owner to retrieve their own marker successfully—a refusal proves nothing if retrieval is broken for everyone. The second principal then attempts the file directly and through the model; the document is deliberately shared to their group; the share is revoked; and the denials are re-tested three ways—direct access, a fresh grounded question, and inside the conversation that had previously succeeded.

Result. Every assessed check passed. The second principal could not read the file’s metadata or its content, and could not obtain it through the model—the answer came back with no marker and no citation. After the intended share, the same principal retrieved the marker with a citation. After revocation they were denied again on all three paths, including the conversation that had worked minutes earlier. The synthetic file, the collection, and its vectors were removed afterward and verified absent.

Durability. The denials were re-asserted across a restart of the application stack, because an access decision that survives only until a cache clears is not an access control. It held: the collection was still refused, a fresh question returned no marker and no citation, and the replayed conversation returned neither.

Verified 2026-09-08 · lab host, signed release v0.6.0. The control step earned its place—the first run failed it, and the check refused to report the second principal’s denials as isolation rather than publish a clean-looking pass that proved nothing.

Current release — single sign-on with group-based authorization

Method. The deployment was federated to a standards-based OIDC identity provider and a fourteen-point identity matrix was driven through a real browser rather than through the API: provider discovery, an assigned user, a user outside the permitted group, MFA enrolment and re-entry, logout, a disabled account, break-glass, and identity egress. Each denial was run with a control in the same harness, so a refusal could be attributed to the thing under test.

Result. Eleven of the fourteen steps were assessable on our own provider, and ten passed:

• The provider is offered at sign-in, and self-registration stays closed.
• A federated user arrives with no access at all and reaches no chat, model or document until they are authorized.
• The group claim in the token creates the matching group and places the user in it, with their role activated—so single sign-on delivers authorization, not only authentication.
• A user outside the permitted group is refused, while the control principal in the same run is admitted, so the refusal is specific to group membership.
• MFA enrolment is forced at first sign-in and a one-time code is required on every login after. Proven with controls: a wrong password gives a credential error, a disabled account gives an account-disabled error, and only an enabled account reaches the code prompt.
• Logout terminates the application session and the provider session.
• A user disabled at the provider cannot start a new session.
• Local password login remains available as the break-glass path when federation is unreachable.
• No identity traffic leaves the boundary—the provider is on-subnet and the host has no default route.

Published session bound. A federated session is valid for eight hours. Disabling someone at your identity provider blocks any new sign-in immediately; it does not reach back into a session already open, because the application issues its own session token once sign-in succeeds. Disabling the account in the application is therefore an explicit, named step of the leaver procedure in our runbook. We publish the bound rather than implying a revocation we do not perform.

Verified 2026-09-11 · lab host, signed release v0.7.0, driven through a browser against a live OIDC provider. The three remaining steps are customer-side by definition—the named owner and calendar reminder for credential expiry, your break-glass restriction and logging policy, and API-key revocation for principals who hold keys. They are recorded against your provider and your policy at acceptance, and the tool refuses to record a step nobody observed.

Current release — destructive restore drill, measured end to end

Method. Plant a marked document and confirm it answers with a citation. Take a recovery-point backup and verify its manifest. Write a sentinel record after the backup, so the drill can prove the system came back from the backup rather than simply never having gone away. Then destroy the running deployment, rebuild it from the backup, and re-query.

Result. PASSED, with a measured recovery time of 856.6 seconds—14 minutes 17 seconds, from destruction to a working authenticated answer. The named administrator came back as an administrator. The planted document and its collection came back, and the marker was returned with its citation. Vector counts matched exactly. Monitoring history survived: the metrics store still answers for a timestamp before the recovery point. And the post-backup sentinel was gone, confirmed directly in the application database—which is what separates a real restore from a stack that kept running. Service validation passed 11 of 11 afterward.

On the number. 856.6 seconds is the honest figure, not the best one. It includes a failed first attempt, because the health endpoint answers before the application can serve an authenticated retrieval. Recovery is not complete until the application works, so the retry stays in the measurement.

Verified 2026-09-11 · lab host, signed release v0.7.0.

Current release — scanned documents, image to cited answer

Method. A PDF with no text layer at all—an image of a page, the way a scanner or a phone camera produces one—containing a distinctive reference code. Upload it through the interface, then ask a question whose answer appears only inside the scan.

Result. The text was extracted, indexed, and retrieved: 278 characters recovered from the page, and the model returned the exact reference code. The same file on the previous release failed with an empty-content error, which is why this is published as a release-dated result rather than a capability.

Verified 2026-09-12 · lab host, signed release v0.7.1.

Current release — backup integrity and signed model reconstruction

Method. Verify the backup manifests on the host and on a separate machine, then import a signed model package into an isolated runtime and try to defeat it three ways: a bad signature, a tampered weight file, and a replayed release.

Result. The manifests verified at both ends (102 files). The signed import completed atomically without activating the package, and the bad signature, the tampered weights, and the replay were each refused before any state changed. Pre-existing runtime state was left intact.

Verified 2026-09-08 · lab host, using ephemeral test-only signing trust. This proves the import and refusal path, not production key custody.

What this covers. This is the import-and-refusal path, proven with ephemeral test-only signing trust; it is not a statement about production key custody. The destroy-and-rebuild cycle is a separate published result above, and neither result claims a rebuild onto a bare host.

Historical results — July 2026, stack revision 89744f5

Everything below this line was produced in July 2026 on rented cloud GPUs at stack revision 89744f5. We keep these results because their methods are intact and the numbers were real, not because they describe the current release. They have not been re-run on signed v0.6.0. Where a current-release result above covers the same ground, the current one governs.

Zero-egress rehearsal — clean capture, zero packets

Method. After staging a system and flipping it to its offline configuration, we logged every new outbound connection to a public address at the host while exercising the stack—model chat, a retrieval data path, a service restart, and a short load test. Two captures were taken, 240 seconds and 100 seconds.

Result. Zero outbound connections to any public address from the AI stack across both captures; the second capture was completely silent—0 packets, 0 bytes of payload. Ordinary internal name resolution stays inside the network and is handled within the standard build. This was a staging rehearsal on our own network, not a customer deployment. The full method is in the zero-egress verification write-up.

Verified 2026-07-16 · rehearsed on our staging network, on a rented A10-class GPU.

Single-GPU serving benchmark — small model (A10-class)

Method. A Qwen2.5-7B model served on the reference stack, swept by the load generator from concurrency 1 through 32 with coherence checked before publication.

Result. 30.6 tokens/sec at concurrency 1, rising to 883.3 tokens/sec aggregate at concurrency 32. Zero failed requests across the entire sweep.

Verified 2026-07-16 · measured on a rented A10-class GPU (24 GB), a proxy for the entry configuration.

Single-GPU serving benchmark — large quantized model (H100-class)

Method. A Qwen2.5-72B AWQ-quantized model on a single accelerator, swept by the same load generator from concurrency 1 through 32, coherence checked before publication.

Result. 43.6 tokens/sec at concurrency 1, rising to 1,262 tokens/sec aggregate at concurrency 32. Zero failed requests across the entire sweep.

Verified 2026-07-17 · measured on a single rented H100-class GPU (80 GB).

Latency correction — 2026-08-23. We withdrew the TTFT p95 values from both July sweeps. The earlier aggregator selected the observation immediately below nearest-rank p95 and did not retain the per-request samples, so corrected latency percentiles cannot be reconstructed. The throughput totals above are unaffected; replacement latency figures require a new run.

Document Q&A, end to end

Method. A document containing a distinctive fact was ingested through the interface, then the same fact was requested back through retrieval.

Result. The system returned the fact with a citation to the source document—an ingest-to-cited-answer path exercised end to end, not a component check.

Verified 2026-07-17 · exercised during staging on a rented H100-class GPU.

Backup and restore drill — full cycle, PASSED

Method. Ingest a document and confirm a cited answer; take a verified backup; destroy live data by deleting all vector-store collections; restore from the backup after its integrity manifest verifies; re-query.

Result. PASSED. After restore, the collections were byte-identical, administrative login worked, and the retrieval query returned the same fact with its citation. A backup that has never been restored is a hope, not a backup—so the drill proves the restore with a real query, not just service health. The procedure is in the backup and restore runbook.

Superseded. This July drill has been replaced by the measured destroy-and-restore cycle on signed v0.7.0 above, which records a recovery time, a recovered document and its citation, recovered monitoring history, and a sentinel proving the data came from the backup. The current result governs; this one is kept for its method.

Verified 2026-07-17 · rehearsed on a rented H100-class GPU during staging.

Stack validation suite — health plus answer coherence

Method. An automated suite run against a freshly provisioned stack: service health checks plus an answer-coherence assertion, because a stack can report every service healthy while still returning low-quality output.

Result. The first end-to-end reference run passed 6 of 6 checks on rented A10-class hardware. The suite also adds a monitoring-scrape verification and the output-coherence assertion, so acceptance confirms the model answers coherently, not merely that services are up.

Verified 2026-07-17 · initial 6/6 run on a rented A10-class GPU (2026-07-16); coherence and scrape checks verified in the current stack revision.

We do not re-run these procedures on a schedule for the sake of a fresher date. They are re-verified when the underlying stack changes in a way that could affect the result—a change to the serving configuration, the telemetry controls, the backup tooling, or the validation suite. Each item above shows the date it was last verified, so you can see exactly how old each claim is rather than trusting a single “last updated” stamp for the whole page.

The current release is signed v0.7.1, source commit 368e2f6, most recently verified 2026-09-12. Results above were produced across signed releases v0.6.0 through v0.7.1 and each names the release it came from, because a result is only true of the release that produced it. The July 2026 items reflect stack revision 89744f5 and are labeled historical above. SkilakSpool is designed to fit within a customer’s CMMC, HIPAA, ITAR, or other security program. Skilak Consulting does not certify or confer compliance.