Pointsman's single-instance v1 Compose profile completed local release qualification on 28 October 2026. Qualification applies to a specific runtime and workload; publication, a version tag and qualification of later runtime changes are separate steps.
Qualification at a glance#
The qualified runtime and the performance candidate have different acceptance states.
| Item | Status | Applies to |
|---|---|---|
| Qualified runtime | Passed local qualification | e71e5da8 and the documented single-instance v1 Compose profile |
| Requirement review | 113 accepted · 10 approved exclusions · 0 pending blockers | Qualified runtime; some cases reuse applicable earlier evidence |
| 12-hour and 24-hour healthy stages | Passed | Frozen workload, configuration and resource bounds |
| Performance candidate | Not yet long-run qualified | Later ONNX worker-scheduling, settlement-SQL and journal-unit changes |
| Publication / released version | Separate release step | Local qualification does not publish or tag a release |
Evaluating this branch: its changed runtime must pass separate long-run qualification. A short benchmark or targeted correctness test does not transfer the earlier runtime's acceptance.
Supported scope#
Use this scope when deciding whether the evidence matches your deployment.
| Area | Qualified scope or default | Outside the established claim |
|---|---|---|
| Deployment | One gateway instance in the documented v1 Compose profile | Multi-instance high availability, multi-region resilience and zero-downtime upgrades |
| Client API | Documented Chat Completions subset | Blanket compatibility with every OpenAI API |
| Routing | Weighted-random is the default | Adaptive cost/balanced routing, LinTS, quality-guarded profiles, judges/cascades and Jev remain experimental and opt-in |
| Workload | 50 scheduled attempts/second in the frozen endurance profile | Maximum throughput or performance above that profile |
| Infrastructure | 640 MiB gateway heap; 2.5 GiB gateway container | A dedicated physical-core guarantee on shared-vCPU infrastructure |
Experimental routing paths still obey tenant, credential, budget and accounting constraints. Their presence does not make every optional integration a qualified deployment.
Qualified source: e71e5da8ad7186aaa4962d331c6ddfd7a9c8320b. Later documentation changes do not expand runtime acceptance.
Qualification summary#
Both governing healthy stages passed without threshold relaxation or a fault exception.
| Stage | Scheduled attempts | Checks and outcome |
|---|---|---|
| 12-hour healthy stage | 2,160,000 | All 12 adaptive and 14 resource checks passed; exact accounting and cleanup |
| 24-hour healthy stage | 4,320,000 | All 12 adaptive and 14 resource checks passed; no unexplained outcomes or reconciliation violations; journal drained |
| 24-hour resource and cleanup review | — | No observed OOM or container restarts; owned run resources stopped; log coverage and sealed evidence identities verified |
Scheduled attempts include deliberate client cancellation. They are not a count of successful responses alone.
Endurance response times include simulated provider time. Use the separate latency and benchmark breakdown to assess gateway timing.
Performance candidate in this branch#
The candidate changes three areas:
- Local embedding: explicit ONNX worker sizing and scheduling.
- Durable accounting: batched settlement SQL with the existing transaction and journal boundaries.
- Usage journal: fewer directory fsyncs, with replacements durable before their old intents are removed.
The read-bypass p99 investigation found the cost in the usage journal's directory
fsyncs, not in PostgreSQL. A further candidate, c8de5d86, forces the journal
directory once per step (four times per request instead of seven) and removes a
replaced record only after that fsync, without changing what is durable before what;
in a matched comparison against 2981c99a both of its read-bypass p99 repetitions were
lower than both controls (37.05 / 37.70 ms against 41.31 / 40.22 ms) with exact
accounting, as its earlier form e6f4d43b, which unlinked before the fsync, had been
(38.21 / 38.11 ms against 41.66 / 41.82 ms). See the
journal unit fusion comparison.
The tested WAL settings were not adopted; the PostgreSQL profile and durability
barriers remain unchanged. See the storage comparison.
The shipped whole-stack crash-resolution drill passed on both forms on 29 October
(45 checks each, none failed; see the comparison's section).
Neither candidate has repeated the 12-hour/24-hour qualification.
See performance validation for targeted tests and the current comparison. The previous 12-hour and 24-hour qualification does not cover these runtime changes.
Observations that remain disclosed#
Cache timeouts#
The healthy stages recorded bounded Redis cache-operation timeouts.
| Observation | 12-hour stage | 24-hour stage |
|---|---|---|
| Cache lookup timeouts | 14 | 29 |
| Asynchronous cache-store timeouts | 9 | 19 |
| FT.INFO fallbacks | 1 | 0 additional |
| Redis command timeout | 50 ms | 50 ms |
No unexpected client outcomes, accounting discrepancy or frozen service-bound failure was observed from these events. Their underlying latency/jitter cause is not established. The qualification does not establish zero cache errors.
Diagnostic and routing limits#
The following observations remain part of the release's limits.
| Observation | Result | Effect on the claim |
|---|---|---|
| Legacy fixed-512-MiB diagnostic | Failed | Not a governing acceptance dependency; the governing resource policy used the bounds listed above |
| Natural-reclaim / drain-pressure observation | Incomplete | Not a governing acceptance dependency |
| Separate real-provider comparison | 1,776 requests; both routers selected the same model throughout evaluation | No established adaptive advantage, quality-preserving savings or superiority claim |
Limits of the claim#
Interpret each signal within its boundary:
- HTTP 200: a stream started; it does not prove completion or answer quality.
- Semantic similarity: an approximate match; it does not prove exact equivalence.
- Usage accounting: gateway estimates or provider-reported usage; it does not independently verify provider invoices.
- Database backup: retained database state; it does not establish spend lost with counter state. Recovery requires independent evidence and the documented procedure.
- Deployment configuration: model capabilities, credentials and external services remain specific to the operator's environment.
Before deploying#
- Check the deployment guide against your topology.
- Review known limitations and the security posture.
- Read the architecture and stage designs for the controls your application relies on.
- Match the runtime and configuration you intend to run to its qualification evidence.