Skip to main content
Every item below is sourced, CLAIMS.md §5 for the permanent refusals, or a specific file/test/live run for everything else on this page.

​
Permanent refusals, CLAIMS.md §5

These are not “not yet” items. Parmana does not intend to ever make these claims unscoped, because no implementation could honestly back them:
  • Execution is impossible to bypass under all circumstances.
  • Mathematical proof of execution correctness.
  • Cryptographic proof of every aspect of runtime behavior.
  • Guaranteed regulatory compliance.
  • Absolute prevention of all unauthorized execution.
  • Tamper-proof operation in every deployment environment.
  • Elimination of all software defects or operational risks.
  • “Non-bypassable” or “the single execution authority” as an unscoped, system-wide claim. The gateway enforces nothing at the network level, and is a property of systems that route through it, not of the network Parmana runs on.
  • Deterministic signature output for ML-DSA-65. Those signatures are randomized by design, only verification is deterministic, see Choose a signature provider.

​
Scoped claims, not absent ones

Some real, tested guarantees hold only within a stated boundary. Treating the boundary as the whole claim is the honest reading:
  • Envelope verification is non-bypassable only for a system that runs it. The default server does, for whichever connectors it registers (currently just hubspot, conditional on its credentials being configured). A system you build that doesn’t call @parmana/envelope-verifier gets none of this.
  • Single-use is scoped to whichever NonceStore instance checks it. Independent gateway instances, each with their own MemoryNonceStore, can each accept the same authorization once, not once fleet-wide (CLAIMS.md 3.2).
  • Credential isolation is proven for the one connector registered in production today, hubspot. (Previously proven only for vendor-payment, a reference connector since removed from the repository entirely, not merely superseded — see docs/VERIFICATION-GAPS.md G-27 in the source repository.) The mechanism is generic and tested, but reaching a second connector is still a bootstrap code change, not something the architecture does automatically, see Credential isolation.

​
Mocks are labeled as mocks

SapConnector, OracleConnector, WorkdayConnector, and SalesforceConnector (packages/connector-sdk/src/connectors/) are explicit, self-documented reference mocks, “deterministic, in-memory connector used until the real enterprise connector is implemented.” None of them calls a real SAP, Oracle, Workday, or Salesforce system, and none is wired into the default server. No real enterprise connector exists in this repository for any vendor. See The gateway and Add a connector with the Connector SDK.

​
Real, tested, and disconnected from the default server

Two packages found during this documentation effort are genuinely built and tested, but don’t participate in the pipeline packages/api actually runs:
  • @parmana/receipt: its ExecutionReceiptBuilder, ExecutionReceiptVerifier, and the separate ExecutionPermit model it depends on (from @parmana/execution-control) are exercised only by examples/tutorials/53 through 56. Nothing in packages/runtime or packages/api imports @parmana/receipt. See @parmana/receipt.
  • @parmana/replay’s ReplayEngine: does genuinely re-evaluate a recorded policy decision, real semantic verification, not a signature recheck, but nothing in packages/api or packages/runtime imports it either. POST /replay is a separate, narrower thing (a signature recheck). See @parmana/replay.

​
Authentication is now real, but it is one layer, not a substitute for the others

packages/api gates every route except GET /health behind a caller bearer key (StaticKeyAuthenticator), verified live this pass. This is a recent addition, and it answers only “should this HTTP request be entertained at all”. It does not prove anything about who authorized the underlying business action, that is still Execution Authorization and gateway attestation’s job, on separate signatures. See Authentication for the full model. What it still does not cover, precisely (updated to reflect the G-24 fix, see Security for the incident this closed): route access itself remains unscoped — any authenticated caller can call any route, there is no per-key allowlist of endpoints. What is now scoped: which authority.principalId a caller may assert (isPrincipalAllowed, default is “only itself,” never “anything”) and which transactions/trust-records/receipts a caller may read (isOwnedByCaller, cross-caller reads now 404). Neither of those existed before 2026-07-28. Still genuinely absent: mutual TLS by default, and a self-service key rotation endpoint (rotation is a manual operator procedure).

​
No key management beyond local files

Both signing keys, default.*.pem and gateway.*.pem, are files on disk read by FileKeyProvider, the only implemented KeyProvider. aws-kms, azure-key-vault, gcp-kms, and hsm are declared as valid config values with zero implementing classes, setting KEY_PROVIDER to one of these does nothing. See Deploy patterns and the key-compromise incident on Security.

​
Error handling: one gap closed, two still open

One of three previously-tracked gaps is now closed: malformed JSON and oversized request bodies on /execute used to surface as a generic, indistinguishable 500 — as of the G-24 session (middleware/error-handler.ts, bodyParserErrorStatus), they now return a clean 400/413 naming which case it was, mirroring the handling the webhook route already had. Verified directly against the current source, not assumed carried over. Two gaps remain open, unchanged: a structurally incomplete POST /execute body (a valid UUID, but missing required nested fields) does not produce the clean 400 the error-handler appears designed to return, it throws an unhandled TypeError deep in validation, caught only by a generic 500. Separately, “no Connector registered for this action” used to reach the caller as a coded RuntimeError, it no longer does, it collapses into the same uncoded 500 as the first gap. See Error handling for both, and the Error catalog for every error this API returns. Neither is fixed as of this pass; the second remains flagged as a product regression.

​
Next

The CLAIMS.md discipline

How to verify any of the above yourself.

Roadmap

What’s designed but not built yet, and the sequencing behind it.