> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Parmana Does Not Claim

> Honest limitations, sourced from CLAIMS.md's own refused claims and from what this documentation effort found while verifying every page against code.

<Info>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.</Info>

## 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](/concepts/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](/guides/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](/concepts/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](/concepts/the-gateway) and [Add a connector
with the Connector SDK](/guides/add-a-connector).

## 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](/reference/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](/reference/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](/concepts/execution-authorization) and [gateway
attestation](/concepts/gateway-attestation)'s job, on separate signatures. See
[Authentication](/api-reference/authentication) for the full model.

**What it still does not cover, precisely** (updated to reflect the G-24 fix, see
[Security](/security/overview) 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](/guides/deploy-patterns)
and the key-compromise incident on [Security](/security/overview).

## 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](/api-reference/error-handling) for both, and the
[Error catalog](/api-reference/error-catalog) for every error this API returns. Neither is
fixed as of this pass; the second remains flagged as a product regression.

## Next

<CardGroup cols={2}>
  <Card title="The CLAIMS.md discipline" icon="shield-check" href="/trust-and-claims/claims-discipline">
    How to verify any of the above yourself.
  </Card>

  <Card title="Roadmap" icon="map" href="/roadmap">
    What's designed but not built yet, and the sequencing behind it.
  </Card>
</CardGroup>