Solipher SHARD Context
Shrinks what you send to an LLM without losing the facts that have to be exactly right, compiled to your model's exact token budget, never an estimate.
The problem, and what SHARD Context actually does.
The problem
LLM applications routinely send far more context into a model than a given request needs, full documents, entire conversation histories, every retrieved source, because trimming it down risks silently dropping the one detail that has to be exactly correct.
The solution
SHARD Context compiles the smallest context package that still fits your model’s exact token budget, without dropping the facts marked as required. Most context-reduction tools compress everything the same way; this one distinguishes a fact that can be paraphrased from one that can’t.
What reaches the model, with and without SHARD Context
If SHARD Context can’t guarantee correctness, it falls back to the original, unmodified request — it never guesses.
The full evidence, generated 2026-07-22
Every number below is from a real run against a live, hosted open-weight model, plus a second, independent clean-room reproduction on a self-destructing cloud VM, no simulation, no projection presented as measured fact.
Test environment
| Primary model | openai/gpt-oss-120b-maas, hosted open-weight (Vertex AI Model Garden) |
| Model families tested | 5: OpenAI, Alibaba Qwen, DeepSeek, Google Gemini, plus OpenAI's smaller size variant |
| Endpoint | Global region, OpenAI-compatible chat completions |
| GCP project | weighty-planet-500504-k6 |
| Tokenizer | cl100k_base-compatible, real token counts, never estimated |
| Codebase | 8-crate Rust workspace, 462 automated tests, 0 regressions |
| Memory safety | #![forbid(unsafe_code)] verified in all 8 crate roots |
| Benchmark machine | AMD Ryzen Z1 Extreme, 8 cores / 16 threads, local, offline |
What each scenario tests
Long-document QA
A real SQuAD-derived passage, real retrieval, real dispatch to the live model.
Conversation memory
A 4-turn dialogue, checking whether a session fact stated earlier is correctly retrieved and covered.
Transparent RAG, with real distractors
Three real documents: one relevant, two genuine, plausible-looking distractors. Does SHARD Context pick the useful one, or just the short one?
Scenario D’s distractor-rejection check was written to fail if SHARD Context pulled an irrelevant document into context. It did fail, on the first live run. Investigation found two stacked bugs in the optional-fill scorer: relevance was being normalized against the wrong candidate pool, and there was no minimum-relevance floor, so a document could occupy budget purely for being “least-bad among leftovers.”
Both were fixed, and the fix was re-confirmed against the live model. That’s the result in the chart below, not a claim it worked on the first try, the honest record of what it took to get there.
Scaled from one 3-document demo to 16 real scenarios, live-verified
16 real, topically distinct articles, fetched from a public question-answering dataset. Each becomes its own scenario: a real question, its own real answer-bearing document, and five other articles as genuine distractors. 64 real offline selection decisions, plus 16 real live compiles against the production GCP project above. Every approach below except SHARD Context let a distractor into the rendered context in all 16 of 16 scenarios, not because the budget was tight, but because none of them stop once the evidence requirement is actually satisfied. Numbers are averages across all 16 scenarios, not one cherry-picked run.
Average tokens reaching the model, 16 real scenarios
Dense (embedding-based) top-K is excluded from this specific 16-scenario chart, that run has not been repeated with it yet. A real Dense top-K adapter (Vertex AI’s text-embedding-005, no OpenAI key needed) now exists and has been run live against a smaller, 3-document comparison instead, see below.
Scaling the benchmark above to 16 scenarios required benchmarking retrieval at real corpus sizes, which surfaced a real, measured problem: BM25 retrieval rebuilt its entire corpus index from scratch on every single call. At 1,000 documents that cost roughly 10.7ms, about 2.1× over the retrieval stage’s own 5ms budget.
BM25 retrieval latency, before vs after the fix
Same benchmark, same three corpus sizes, re-measured after the fix, not a different test.
Log scale, bars are not proportional to raw value
The fix: the index is now built once, when the snapshot is indexed, instead of on every query, since both are pure functions of an immutable snapshot. Re-measured with the same benchmark: a 97.6% latency reduction at 1,000 documents, with zero regressions across the workspace’s 470-test suite.
Independently reproduced on a machine that had never run this code before
A fresh, ephemeral cloud VM was given only the source code, told to build it, test it, and run the same live evaluation, then upload its own logs and delete itself, no human touching the machine after creation.
The startup environment's $HOME was empty, which broke the Rust toolchain's own PATH setup, an environment bug, not a code bug. The VM still uploaded its logs and deleted itself on schedule.
Same source, same live model, fixed environment. Re-confirms the fix from Attempt 1's own diagnosis holds on hardware that had never run this code before.
Real model portability, tested across five distinct model families
The runtime adapter layer claims to work with any OpenAI-compatible endpoint. Rather than guess at model identifiers, every candidate below was probed live with a direct API call first, before committing to a full 16-scenario run. Zero incorrect selections across any model, any scenario, in this entire pass, every error was a rate limit from this session’s own call volume, never a wrong document.
Correct selections out of 16 real scenarios, per model
Every candidate probed live before a full run; every gap shown is a rate limit, never a wrong answer.
Single-scenario portability check, not a full 16-scenario run
Zero incorrect selections across any model, any scenario
Baseline vs SHARD Context, distractor inclusion rate, per model
The offline baselines never call a model, so their 100% rate is a fixed reference line. What varies per model is SHARD Context's own real result, zero, every time.
A real reliability finding, not glossed over: Qwen intermittently returned a response that failed atom extraction’s strict JSON parse on one attempt, succeeding cleanly on immediate retry with the identical input, real model sampling variance, not a SHARD Context defect, and exactly the class of failure this project’s own fail-closed validation already handles cleanly. Claude, Grok, and Kimi were attempted and honestly reported as blocked (see Not Yet, Honestly below) rather than forced by guessing more model ids.
Baseline vs SHARD Context, per model: latency, tokens, throughput
The same real, small, controlled sample (3 real scenarios, same prompt shape, same live model), run once against the full 6-document baseline context and once against SHARD Context’s own compiled 1-document output, so the comparison holds within each model, not just across them. Every model reached a full n=3 sample on both conditions; several calls hit real transient 429s and were retried rather than left as gaps.
Tokens per call
n=3 per condition
n=3 per condition
n=3 per condition
n=3 per condition
n=3 per condition
API call latency
n=3 per condition
n=3 per condition
n=3 per condition
n=3 per condition
n=3 per condition
Throughput (1 / latency)
n=3 per condition
n=3 per condition
n=3 per condition
n=3 per condition
n=3 per condition
Tokens show a clean, consistent reduction for SHARD Context across every single model. Latency does not, one model (DeepSeek) was actually slower with the smaller, compiled context, since API response latency at this call size is dominated by network and queueing variance, not prompt size. Reported as measured, not smoothed into a cleaner story.
Does compiling down to less context ever change the answer?
Every earlier check verified document selection, never the actual final answer text. Real test: the same question, asked twice, once with the full 6-document context (the relevant document plus 5 genuine distractors) and once with only SHARD Context’s own compiled, 1-document output, against the same live model.
| Question | Ground truth | Full context | SHARD Context |
|---|---|---|---|
| How many full time teachers does Victoria have? | 63,519 | 63,519 | 63,519 |
| Which country today is a remnant of the Ottoman empire? | Turkey | Turkey | Turkey |
| When was Warsaw ranked as the 32nd most liveable city? | 2012 | 2012 | 2012 |
All 6 answers (3 scenarios, 2 conditions each) matched the ground truth exactly, and full context vs. SHARD Context produced identical answers every time. A real, small sample on one model, not a comprehensive claim, but a real, previously missing check now actually run.
Dense (embedding-based) top-K, closed for real, against Vertex AI
The one required baseline this project could not run live before now had a real, working algorithm (cosine similarity ranking) with no real embedding model behind it. A new adapter calls Vertex AI’s own text-embedding-005endpoint, no OpenAI key needed, run live against the same 3-document teacher-count scenario used throughout this page. Honest result: at that scenario’s token budget, Dense top-K included all three documents, the same distractor-inclusion outcome every other simple baseline already showed here, since the budget was generous enough to fit the whole small corpus regardless of similarity ranking. Not a favorable result, reported anyway.
CPU cycles, the last named Stratum A output, measured for real
Stratum A (the controller microbenchmark) names CPU cycles as one of its own required outputs, alongside compile latency, RPS, RAM, determinism and terminal-state distribution. It stayed honestly unmeasured for a while, since deriving a cycle count from wall-clock time and an assumed CPU frequency would be a fabricated precision under turbo boost and throttling, not a real measurement. Real hardware performance counters (Linux perf_event_open) close that gap instead, read directly from the CPU, not derived.
Cycles and instructions per compile() call
2,000 real compile() calls, the same clean-dispatch scenario used throughout Stratum A.
Real Linux (WSL2 Ubuntu, kernel perf_event_paranoid=2), hardware performance counters via Linux perf_event_open, not wall-clock/assumed-frequency
A real, live prompt-injection test, broadened, and a real gap it found
Two hostile documents were run through the live pipeline against three model families (Alibaba Qwen, Google Gemini, DeepSeek). A loud, explicit injection asking the model to fabricate a citation succeeded against two of the three models, but the system’s own existing validation rejected the unknown id every time and failed the request closed, no fabricated citation ever reached the output. A quieter injection, keeping the real document id but asking the model to falsely certify unrelated content as exact evidence, succeeded against two of the three models, a real gap: nothing previously checked that self-reported “exact” classification against the document’s own text. Fixed by requiring the model to supply the literal quote it claims answers the question, and verifying that quote is an actual substring of the document before honoring the claim, otherwise it is downgraded to the weaker “derived” classification. Stated plainly at the time: this closed the specific trust gap in that self-report, it did not by itself verify that a selected document is topically relevant to the query. That gap is now closed too, with a real embedding-backed check (cosine similarity between the query and the claimed quote, via the same real Vertex AI embedding model used elsewhere on this page), gating the claim the same way. Re-running the exact quiet-injection scenario live against Qwen and DeepSeek with the new check enabled gave an honest, unglamorous result: the compile outcome was unchanged, because that specific query’s atom was never classified high-risk, and the weaker “derived” classification the check correctly downgrades an irrelevant quote to remains legitimately sufficient for an ordinary atom’s coverage requirement, by design. The real, verified effect of both fixes together is narrower and more honest than “blocks the attack”: they stop an unverifiable or irrelevant self-reported “exact” claim from being trusted for the one thing that classification actually gates, high-risk-atom eligibility. Evidence across three models on two crafted payloads, reported exactly as found, including what neither fix solves.
From a library to a real service: a listening endpoint, mandatory access control, a server-backed viewer, and hardware-backed key management
Four structural pieces landed together, each verified live against the production GCP project above before moving to the next, not claimed in a batch at the end. Together they turn SHARD Context from something you had to embed as a Rust crate into something you can point an existing OpenAI-compatible client at directly.
Test count, per feature landed
Every feature below shipped with its own new, real tests passing first.
Every feature landed with its own new, real tests passing before the next one started, not one bulk test count claimed at the end.
A real listening HTTP proxy
A standard POST /v1/chat/completions request, unmodified, gets a real compiled answer back. Live-verified against the production GCP project: a real question returned HTTP 200 with a real, context-grounded answer; the same request under an artificially tight budget returned HTTP 503 with the exact reason, AbstainBudget, and no model was ever called. Binding to a public address without an explicit override was refused at startup, verified live, not just asserted in code.
Authorization, checked twice per request, not described once
Every request now needs a real principal (tenant, subject, and roles). Access is checked once before retrieval and again immediately before rendering, a real, independent second check, not a formality: a test proves a document authorized at the first check but revoked before the second is correctly refused, even though the compiler had already decided to dispatch internally. Four real requests against the same single-document corpus, live:
x-shard-context-principal:
tenant-a/subject-1/read:evidence
HTTP 200
x-shard-context-terminal: compiled
"Packet switching transmits data in
packets, each with a header and payload..."(no x-shard-context-principal header)
HTTP 401
"missing required x-shard-context-principal
header ... a principal claim is still required"x-shard-context-principal:
tenant-b/subject-2/read:evidence
HTTP 503
x-shard-context-terminal: abstain
terminal_detail: AbstainInsufficientEvidencex-shard-context-principal:
tenant-a/subject-3/read:pinned
HTTP 503
x-shard-context-terminal: abstain
terminal_detail: AbstainInsufficientEvidenceA matching role name from the wrong tenant never sees the document, tenant isolation held even under a deliberately confusing test. Being in the right tenant with the wrong role didn’t help either, role grants are not a formality.
A server-backed viewer, tenant-isolated
The compiled-output viewer previously kept history in browser local storage only, nothing shared across machines. It now also connects live to a running SHARD Context server: every request is recorded into a real, persisted, tenant-scoped history, fetched by the viewer over a real cross-origin request. Live-verified: two different tenants each saw only their own real runs; the server was killed and restarted, and its history reloaded correctly from a real file on disk rather than being lost; switching the principal field in the actual browser correctly switched which tenant’s real run rendered.
Real key rotation, and a real hardware-backed signer
Signing keys now carry an explicit Active, Retiring, or Revoked status. Verified live: a signature made under a key, before that key is rotated out, still verifies through the transition window once a new key takes over, then genuinely stops verifying once the old key is explicitly retired, never a silent, automatic expiry. Separately, a real Google Cloud KMS key now signs live, the private half of which never leaves Google’s hardware. A real attempt to create that HSM key using this project’s existing Ed25519 algorithm was rejected by the live Cloud KMS API, HSM protection level does not support Ed25519 there, so the HSM key genuinely uses ECDSA P-256 instead, reported as found rather than smoothed over. A real message was signed by a live call to that key, verified locally, and a tampered copy of the same message correctly failed verification against the same signature.
Two real installation paths, both actually run, not just written
Docker had to be installed on the test machine first, since it wasn’t there. The image was then built and run against the live GCP project above with real mounted credentials, and the install script was run end to end on a real machine, ending in a real version print from the installed binary.
docker build -f docker/Dockerfile -t shard-context-cli .
docker run --rm shard-context-cli --version
docker run --rm \
-v ~/.config/gcloud/application_default_credentials.json:/home/shard/.config/gcloud/application_default_credentials.json:ro \
-v $(pwd)/data:/data:ro \
shard-context-cli compile --config /data/config.toml --document /data/doc.txt --query "..."bash docker/install.sh
gcloud auth application-default login
shard-context-cli compile --config <path.toml> --document <path> --query <text>That verification work found and fixed a real bug: the CLI hardcoded every document’s id to the literal word “document”, which collided with the extraction prompt’s own JSON field name closely enough to reliably make the live model hallucinate a fabricated citation. Fixed by deriving the id from the document’s own filename instead.
What's real today, and what isn't yet.
This is implemented and measured against a live workload, not a specification anymore. It also isn't finished. Both things are true at once.
Real today
- A working, tested compiler pipeline, not a prototype: ingestion, retrieval, scoring, mandatory-cover and optional-fill solvers, structural firewall, all with real test coverage
- Baseline comparison scaled to 16 real scenarios, live-verified: 0% distractor inclusion, 83.6% fewer tokens than every offline baseline
- A real retrieval budget violation found and fixed at the root, 97.6% faster at 1,000 documents, re-measured, zero regressions
- Security CI gates wired into real automation: fmt, clippy, forbid(unsafe_code), overflow checks, 608 tests, fuzzing, dependency scanning
- Docker image and bare-metal install script, both actually built and run end to end against the live GCP project
- Real adapter portability tested across five distinct model families (OpenAI, Alibaba Qwen, DeepSeek, Google Gemini), zero incorrect selections, plus real prompt-injection tests across three model families that found and fixed a real self-report trust gap
- A real, embedding-backed topical-relevance check on top of the quote-verification fix, re-tested live against the same adversarial scenario, with the honest result (and its real limit) reported, not just the fix
- Independently reproduced from a clean environment, not just re-run on the machine that built it
- A real standalone HTML viewer for compiled output, verified against a live compile's own --json-out file, not a mockup, now with real multi-run history and a side-by-side hash-diff compare mode, verified in a live browser session including surviving an actual page reload
- All five required baselines now run live, including Dense (embedding-based) top-K via a real Vertex AI text-embedding-005 adapter, no fake embedder anywhere
- Cross-architecture replay-hash CI: the hash and canonical-encoding primitives every structured replay hash is built on are verified byte-identical on a real x86_64 runner and a real aarch64 runner in the same CI run, not just proven on one architecture
- Real Ed25519 snapshot signing (ADR-0016): a signed snapshot's tampered content is detected by an actual test that mutates it after signing, not just a construction check. Now joined by real key rotation and a real, hardware-backed signer, both closed for real, see below
- The ECHO-C ablations baseline, real: disabling the structural firewall alone (leaving the mandatory solver and everything else untouched) let a policy-violating selection incorrectly dispatch in a test built to prove exactly that, the single most consequential finding this evaluation work has produced
- Real p95 compile-latency measurement found a real problem at the architecture's own maximum caps (~2-3x over its own stated budget), and it's now fixed: a persistent, structurally-shared data structure replaced a clone happening ~131,000 times per solve, ~4x faster, re-measured and now inside budget, with the same full test suite (including exact-order determinism and concurrency tests) passing unchanged
- The Stratum A controller microbenchmark, real: real compile p50/p95/p99, real single- and multi-threaded requests-per-second, real process memory via a live OS query, real repeated-call determinism, and a real terminal-outcome distribution across engineered scenarios that surfaced an honest, unexpected finding, reported as found rather than smoothed over, and since traced to a real root cause and fixed (see below)
- Mandatory recall and Evidence support, the last two named evaluation metrics, now computed for real on every live run, not just tracked as informal proxies. Mandatory recall cites the spec's own definition directly; Evidence support has no formula in either spec document, so its definition is stated as this project's own proposed reading, named honestly rather than presented as authoritative
- Long-document QA and conversation-memory scenarios (Strata B and C) scaled beyond a single smoke test, matching the transparent-RAG scenario count expansion done earlier, all run live
- The Reference Baseline frozen for real, then genuinely revised: version 1 sealed a real digest of the actual compiled source bytes plus the real evaluation-fixture ids from live runs. Once the larger corpus, the persisted snapshot, the hardware disclosure and the rest landed, moving to version 2 required a real, documented revision decision naming who made it and why, and the same run demonstrates the guard rejecting an undocumented one. Not a version number bumped by hand
- A real, signed snapshot artifact can now be written to and read back from an actual file on disk, closing a gap this project had named in its own code for a while: loading a snapshot from storage now verifies its signature automatically and rejects a tampered file, demonstrated live with a real adversarial edit that gets correctly caught
- The evaluation corpus scaled to 48 distinct real articles, the actual ceiling of the public dataset it draws from, not an arbitrary bigger number. Every offline baseline still lets a distractor through 48 out of 48 times; SHARD Context's own live selection stayed correct in 44 of 48 real scenarios, with the 4 exceptions matched exactly to two real, named limits found and reported alongside the results, not hidden
- The exact hardware every benchmark number on this page was measured on is now disclosed project-wide, not just for one dated chart: real CPU, RAM, OS, Rust toolchain and compiler flags, queried directly from the running machine rather than estimated, alongside an honest statement that it's a shared development machine, not an isolated benchmark rig
- Dense (embedding-based) top-K, the one required baseline still tested on only a 3-document comparison, is now re-run live across the full 48-scenario corpus too, closing the last gap in that comparison table. It behaves exactly like the other simple baselines at this budget: everything fits, so it includes the distractor every time, the same real story the rest of the table already tells
- Access control on the local telemetry trace is now really enforced, not just described: a caller is checked against both the tenant the data belongs to and the permission its role carries, with the two failure reasons kept separate so a wrong-tenant attempt is never mistaken for a wrong-permission one. Telemetry can also now be grouped and merged by real, explicit categories, with a test proving that permissive grouping can never be used to leak data across tenants
- The earlier finding that one of the six possible outcomes could never actually happen has been root-caused and fixed: the internal solver was quietly treating two different situations, no usable coverage at all versus coverage that simply cost too much, as the same result. Re-measured live, all six outcomes now occur, evenly, exactly as the design always intended
- The baseline comparison was re-run under a real, tight token budget for the first time, rather than one so generous nothing ever had to be left out. The result is the strongest evidence yet for why this approach exists: at a 100-token budget, the two 'smart,' relevance-ranked baselines drop the actual correct document in 46 of 48 real scenarios, while still spending part of that budget on an unrelated one. They rank correctly, then run out of room for the answer, real behavior, not a hypothetical, and it disappears as the budget loosens, exactly as the mechanism predicts
- SHARD Context's own selection was then tested at those exact same tight budgets, closing the comparison. Across every budget from 100 tokens up to 1,000, it dropped the correct document zero times, in 47 real scenarios each. At the tightest budget it mostly reports, honestly, that it cannot fit a safe answer at all, rather than guessing, the same real distinction the fixed sixth outcome above exists to surface. This is the mechanism working as designed: covering the required fact is treated as a hard requirement solved on its own terms, never a best-effort ranking that can be crowded out by a smaller wrong answer
- A gap in the topical-relevance check named honestly for a while has been closed at the root: an off-topic quote used to only get relabeled internally, a relabeling that turned out to have no actual effect for an ordinary, non-critical fact. Now an irrelevant quote is discarded outright, and a real test proves the specific document it came from can no longer satisfy that fact's coverage requirement at all, for any fact, not only the high-stakes ones the original fix covered
- The ablations baseline now covers all four named components, not three: stable-prefix/dynamic-tail packet classification is real and wired into the one place it's actually rendered, routing pinned, version-stable facts into a canonically ordered, cache-friendly prefix instead of leaving everything in the dynamic tail. Proven, not just built: a test shows the split can only change where a packet renders, never which packets get selected, and a second test proves two requests sharing the same pinned fact but differing everywhere else still render a byte-identical, reusable prefix
- CPU cycles, the one Stratum A output this project had named as honestly unmeasured (a wall-clock-and-assumed-frequency number would have been a fabricated precision, not a real one), are now measured for real: actual Linux hardware performance-counter reads, not an estimate, verified on real hardware at 6.17M cycles and 20.29M instructions per compile() call. Falls back to an honest "not measured" message, never a guess, on any OS or sandboxed environment without counter access
- SHARD Context is now a real, listening HTTP service, not only a library you embed. A standard OpenAI-compatible POST /v1/chat/completions request, unmodified, gets a real compiled answer back with real x-shard-context-mode/-terminal/-decision-id headers, live-verified end to end against the production GCP project. Refuses to bind to a public address by default, verified live: it will not start on 0.0.0.0 without an explicit override
- Authorization is now mandatory and checked twice per request, before retrieval and again immediately before rendering, not described once and assumed to hold. A real test proves the second check is load-bearing: a document authorized at the first check is revoked before the second, and the second check catches it and refuses to render even though the compiler had already decided to dispatch. Live-verified: the right tenant and role gets a real compiled answer; the wrong tenant, even with a matching role name, gets refused with no data exposed; the right tenant with the wrong role gets the same real refusal
- The compiled-output viewer is no longer browser-local only. A running shard-context-proxy now records every request into a real, tenant-scoped run history, fetched live by the same viewer over a real cross-origin request. Live-verified: two different tenants each see only their own real runs, the server was killed and restarted and its history reloaded correctly from a real file on disk, and switching tenants in the actual browser correctly switched which tenant's real run rendered
- Real key rotation: signing keys carry an explicit Active, Retiring, or Revoked status, and a signature made under an old key keeps verifying through a real transition window after a new key takes over, then genuinely stops verifying once the old key is explicitly retired. Verified live end to end, not just asserted
- Real hardware-backed signing via a live Google Cloud KMS key. A real attempt to create that key using this project's existing Ed25519 algorithm at HSM protection level was rejected by the live API, so the HSM key genuinely uses ECDSA P-256 instead, the algorithm Cloud KMS's HSM tier actually supports, reported as found rather than smoothed over. A real message was signed by a live call to that key, the private half of which never leaves Google's hardware, and verified locally, with tampering correctly detected
Not yet, honestly
- Claude, Grok, and Kimi are not yet tested. Claude returned a real "no access" response from Vertex, an account-level enablement step, not a code gap. Grok and Kimi were not found under any model id tried, and may not be offered on this platform at all.
- Adversarial testing so far covers two crafted prompt-injection payloads against three model families, real evidence, not a comprehensive red-team result.
- Scaling the real corpus to 48 articles surfaced two genuine limits, reported rather than smoothed over: a fixed relevance floor doesn't cleanly separate every distractor once two articles share enough real vocabulary (Harvard and University of Chicago, both being about American research universities, being the clearest case), and asking a live model to cite one specific passage among many occasionally gets a citation wrong, a case an existing check catches and rejects rather than silently misattributing.
- The static document corpus a running shard-context-proxy serves is loaded once at startup from config, not a live document-management API. Adding a document means restarting the process with an updated config, a real, named simplification, not an oversight.
- Key rotation and HSM-backed signing are two separate, real trust roots today (Ed25519 for local signing, ECDSA P-256 for the Cloud KMS HSM path), not yet unified into one key-ring abstraction. Google Cloud KMS does not support Ed25519 at its HSM protection level, confirmed against the live API, which is why the algorithms differ rather than one silently standing in for the other.
Get in before the general benchmark.
For teams who want early access to a measured, working implementation, and input into what gets evaluated next.
Register interest as a design partner
Direct engineering access, input into what gets evaluated next, and first access once benchmarked against your own workload.
Looking for the broader admission-control side of the AI infrastructure line? See SHARD Gateway.