This is how the SRD Engine API works. You send an input and a witness - the object to evaluate. SRD reasons over it, and the verifier gates the output: an exact accept when the relation holds, a precise diagnostic when it does not. The shape is the same across every verify.* domain.
POST input + witness -> SRD reasoning -> verifier-gated status
Engine internals remain sealed. Public outputs are measured and verifier-gated.
How the API works
Every call carries an input and a witness - the candidate object to evaluate against an exact relation: a factor pair, a key, an assignment, a proof step, a model, or a candidate restore. SRD reasons over the input and checks the witness. The verifier returns an exact accept when the relation holds, or a precise diagnostic when it does not. The output is never a guess and never a fake pass.
POST the input and the witness for the domain you are calling: factors, a key, an assignment, proof steps, a model, or a candidate restore. The witness is the object the verifier will check.
The engine reasons over the input using SRD and evaluates the witness against the stated relation. The check is deterministic and exact - no sampling, no approximation.
The response carries a status from a fixed taxonomy plus, where applicable, a SHA-256 proof record. An accept is exact; a diagnostic says where the witness failed.
Endpoints
Each domain is a measured capability with the same witness-gated shape: send the input and the witness, get back a verifier-gated status. Every domain ships with a measured benchmark and a published proof object.
Witness: a supplied .pdli. Restores it byte-for-byte and confirms the SHA-256 of the restored output matches the original.
Witness: a candidate assignment. Checks it against the supplied clause set and reports whether every clause is satisfied.
Witness: a supplied proof. Walks it and verifier-checks each step is a valid inference, returning an exact accept or a precise diagnostic.
Witness: supplied factors. Confirms they multiply back to N and returns an exact gated accept or diagnostic. Verifier-gated, authorized-scope only.
Witness: a supplied key. Re-encrypts and confirms it reproduces the AES-GCM ciphertext, gated by the verifier. Verifier-gated, authorized-scope only.
Witness: a candidate model. Checks it replays the observed traces exactly. If it cannot reproduce them, you get a diagnostic.
MDP / game: measured value and policy equivalence under a stated symmetry, returned as a verifier-gated correctness result.
Diagnostic of OOS, cost, slippage, drawdown and leakage on a supplied strategy. No ROI, no Sharpe - just the checks.
Produces SHA-256 and timestamp proof assets so a result can be checked and dated by anyone, later.
Request / response shape
Every call is the same: you POST an input and a witness for the chosen verify.* domain. The response carries a verifier-gated status, a human-readable note, and - where applicable - a SHA-256 proof record. The fields below are stable across all domains.
Request
POST /v1/verify.rsa
Content-Type: application/json
Authorization: Bearer <api_key>
{
"domain": "verify.rsa",
"input": { "N": "<modulus>" },
"witness": { "p": "<factor>", "q": "<factor>" },
"proof": { "record": true }
}
Response
{
"domain": "verify.rsa",
"status": "DELIVERED_VERIFIED",
"accepted": true,
"relation": "p*q == N",
"note": "witness satisfies the relation",
"proof": {
"sha256": "<hex digest>",
"timestamp": "2026-06-19T00:00:00Z"
}
}
domain selects the verify.* endpoint. input is the problem instance. witness is the candidate object to check. proof.record requests a SHA-256 proof asset.
status is one of the fixed taxonomy values. accepted is the gated boolean. relation states what was checked. note is the diagnostic. proof carries the SHA-256 record when requested.
Diagnostic example (witness does not satisfy the relation)
{
"domain": "verify.sat",
"status": "SUPPORTED",
"accepted": false,
"relation": "every clause satisfied",
"note": "clause 17 unsatisfied under supplied assignment",
"proof": { "sha256": "<hex digest>" }
}
A diagnostic is a true result: it tells you precisely where the witness failed. The verifier never returns a fake pass and never guesses.
Verifier-gated status
Every response carries exactly one status. The taxonomy is fixed, so a caller always knows how much weight a result can bear - from a measured, delivered verification down to a labelled research candidate.
| Status | What it means | How to read it |
|---|---|---|
| DELIVERED_VERIFIED | The witness was checked against the exact relation and the verifier accepted. A measured benchmark and a published proof exist for this domain. | An exact accept. This is the strongest result - the relation holds and a proof record can be produced. |
| SUPPORTED | The domain is a measured capability and the verifier ran, returning a precise diagnostic - the witness was checked but did not satisfy the relation. | A true diagnostic, not a failure of the engine. The note says exactly where the witness fell short. |
| SRD_OPEN | SRD reasoned over the input but no witness was supplied, or the supplied object is outside the relation this domain gates. Nothing was accepted. | Bring a witness in the domain's shape and re-call. No claim is made either way. |
| RESEARCH_CANDIDATE | The surface is part of our research direction. It is labelled research, not delivered - there is no measured benchmark or published proof behind it yet. | Treat as research only. No production weight; no claim runs ahead of the evidence. |
A capability ships with status DELIVERED_VERIFIED or SUPPORTED only when it has a measured benchmark and a published proof. Anything still under research returns RESEARCH_CANDIDATE and is labelled research, not delivered.
What stays sealed
The API exposes inputs, witnesses, verifier-gated statuses and proof records. The engine internals that produce SRD reasoning remain closed. This is the self-sealed model: you get proof without disclosure - a result you can check, with the mechanism that produced it kept private.
The request you send, the verifier-gated status, the stated relation, the diagnostic note, and the SHA-256 proof record. Everything needed to check a result.
The engine internals that produce SRD reasoning are sealed. The API surface is the public contract; the mechanism behind it is not disclosed.
A proof record is independently checkable: re-hash the restored output, re-multiply the factors, re-run the clause check. The result stands on its own evidence.
YOU BRING
input + witness
VERIFIER RETURNS
gated status + proof
FAQ
Run the witness-gated API on your own input and see an exact accept or a precise diagnostic. Then check the measured benchmarks for yourself.
Witness-gated API - measured domains, verifier-gated statuses, bounded by measurement
Lossless compression and orchestration are available as a separate Pedulli product.