Roadmap

What’s designed but not built, stated plainly, this is a feature of this documentation, not an apology.

Every item on this page is [ROADMAP] unless a specific sub-point says otherwise. None of it ships in the current server by default.

This page consolidates every gap surfaced while building this site, cross-checked against docs/CLAIMS.md §4 (Future Claims) and the internal strategy document UNAVOIDABILITY-ARC.md (2026-07-05). Both are being updated to reflect the current state as a follow-up (tracked in 02-REMAINING.md, Tier 0), this page reflects the true current state now, not the slightly-stale wording in those two files.

The unavoidability arc, 3 moves, in dependency order

“The provability layer is done: every approved action carries a signed, content-bound, single-use authorization that receiving systems verify independently, byte-for-byte. What that does NOT yet do: it makes Parmana’s authorization verifiable, not unavoidable. Today an AI still holds whatever execution credentials it was given.” Source: UNAVOIDABILITY-ARC.md, 2026-07-05

The last sentence of that quote is now partially stale, in a good way. As of commit 651497a (2026-07-11), the default server wires the gateway unconditionally and routes every connector it registers through credential isolation: for razorpay:refund-create and hubspot:deal-update specifically, the calling AI does not hold the execution credential, the gateway does, briefly, and only inside its own boundary. (A third connector, vendor-payment, was the original evidence for this claim; it has since been removed from the repository entirely — see docs/VERIFICATION-GAPS.md G-27 in the source repository — and its replacement evidence, two real connectors making genuine external API calls rather than one MockConnector returning a scripted success, is materially stronger than what it replaced.) Move 2 below is updated accordingly. Move 1 and Move 3 are unaffected.

Move 1: KMS / HSM key custody, [ROADMAP], roughly 1-2 weeks once started

Today: FileKeyProvider reads a PEM file from disk (KEY_PROVIDER=local, the only implemented provider). KeyProviders declares aws-kms/azure-key-vault/gcp-kms/hsm as config values with zero implementing classes. This is the exact exposure class that produced the committed-key incident on Security.

Unlocks: “Parmana’s signing key cannot be exfiltrated from the application process.”

Open design questions (from the strategy doc, not yet resolved): does AWS KMS support Ed25519 natively, or does this force a move to ecdsa-p256 (already declared in SignatureAlgorithms)? ML-DSA in KMS is not yet broadly available. The claim only promotes to Supported once a live test against a real KMS key has run, a fake/mock passing proves nothing here.

Move 2: Credential brokering, [PARTIAL], wired for two connectors, full claim is [ROADMAP]

Today, precisely: packages/execution-control is real and tested (11 tests) and, as of commit 651497a, wired into the default server: ExecutionControlService authenticates a calling gateway, issues a short-lived InMemoryGatewaySessionStore session, and only then invokes a connector, auditing every step. InMemorySessionCredentialVault isolates the credential from the caller within that flow. This is real, tested, and running in the default server for the two connectors currently registered (razorpay, hubspot), see Credential isolation for the precise scope note. It is still an in-process, in-memory scaffold, not a cross-system claim about arbitrary connectors, landed 2026-07-05 as a library, wired into the server 2026-07-11.

What’s still missing for the actual claim: real cloud-provider credential minting (the plan targets AWS STS: a verified envelope causes the gateway to mint a short-lived, action-scoped credential, use it, and discard it, the AI never receives it, structurally), and a general-purpose path to register a new connector into this seam without a bootstrap code change. InMemorySessionCredentialVault and InMemoryGatewaySessionStore are dev/reference-grade names for a reason, no STS integration, no persistence, no cross-process session sharing exists yet. The strategy doc is explicit that this move “needs a design partner, not a mock”, a fake AWS account proves nothing a diligence review would trust.

Unlocks (scoped): “For [action class] on AWS, AI never possesses execution credentials.” Scoped to the integrated system class, never claimed universally.

Schema note: extending the envelope with resource/action fields for this is a signed-artifact format change, requiring a dedicated versioned session (the version field already in ExecutionAuthorizationPayload exists for exactly this reason).

Move 3, Network enforcement + bypass detection, [ROADMAP], needs a partner’s red team

What: network-policy templates (firewall / security-group / K8s NetworkPolicy) so a target’s ingress accepts traffic only from the gateway, plus a reconciliation loop comparing the target’s own activity log against issued authorizations, anything without a matching envelope raises an alert.

Why last: it’s a property of a customer’s deployment, proven by a partner’s security team trying to break it, not by a unit test.

Unlocks (permanently scoped): “Non-bypassable per integrated system under the reference deployment; bypass detected everywhere.” The unscoped “non-bypassable, period” claim is never made, see Security.

Other tracked gaps

Item	Status	Detail
Additional SDKs (Go, Java, .NET, …)	[ROADMAP]	No source exists. See Other Languages.
Real third-party connectors (SAP, Salesforce, Oracle, Workday, …)	[ROADMAP]	HttpConnector and MockConnector are reference implementations; four enterprise-named connectors exist as explicit, self-documented mocks (packages/connector-sdk/src/connectors/{sap,oracle,workday,salesforce}/), deterministic, in-memory, standing in until a real one is built. None of the four is wired into the default server’s connector registry. See The gateway.
postgres / sqlite storage providers	[ROADMAP]	Declared in the type union, throw “not implemented” at construction. See Storage.
Replay semantic verification of the full record	[ROADMAP]	POST /replay is a signature recheck only. packages/replay’s ReplayEngine does genuinely re-evaluate the recorded policy decision, real, tested, verified live, but scoped to one execution and disconnected from the API. CLAIMS.md §4’s broader “every trust artifact” claim remains unbuilt. See Replay.
Algorithm migration (re-key Ed25519 → ML-DSA-65, verify old records)	[ROADMAP]	AuthorizationVerifier supports exactly one configured PRIMARY_SIGNATURE_PROVIDER at a time.
Structured logging / observability	[ROADMAP]	LOG_LEVEL is parsed into config; nothing currently reads it to configure a real logger. Errors go to console.error. No metrics, tracing, or dashboards exist.
Nonce store persistence (Redis-backed)	[ROADMAP], partially superseded	SupabaseNonceStore (createNonceStore.ts) is the default outside NODE_ENV=test and is durable across restarts and shared across replicas pointed at the same Supabase project. MemoryNonceStore is now the NODE_ENV=test / hermetic-example path, not the only implementation. A Redis-backed store, for deployments that want durability without a Postgres dependency, remains unbuilt.
Authority/Intent/Evidence verification checks	[ROADMAP]	Only integrity, signature, and authorization-binding exist in verification-service.ts today (CLAIMS.md 2.15/§4). Open question on record: does an Authority check add anything the signature check doesn’t, before a key/authority registry exists?
Fetch-verification of unbound policy signals	[ROADMAP]	Policy.boundSignals (landed 2026-07-28, see Security) only binds the specific signal keys a policy author declares — it does not independently verify that an unbound signal (vendorVerified, paymentApproved, riskScore, and similar) is actually true; those remain caller-declared attestations. razorpay-refund/1.0.0 binds only requestedRefundAmountPaise; every other signal that policy evaluates (paymentStatus, paymentCurrency, the refundable remainder, the daily cumulative cap) is unverified for a request reaching it through the generic POST /execute route, see Razorpay for the precise scope. Closing this for real means extending RazorpaySettlementProcessor’s fetch-verify pattern to policy signals generally — real, valuable, materially larger than the binding fix, and not scheduled.
API authentication	Shipped, see Authentication	Caller bearer-key authentication is real and fails closed by default (createCallerAuthenticator.ts, commit 5c688b4). What’s still [ROADMAP]: a self-service key-management endpoint, issuing and rotating keys is an operator action today, not an API call.
POST /policies/validate semantics	Flagged, not scheduled	Validates policy-existence, not a submitted document, naming mismatch. See core-API findings.
POST /transactions vs POST /execute duplication	Flagged, not scheduled	Same core-API findings note.
A general-purpose way to register a new connector	[ROADMAP]	Today, adding a connector to the running server means editing createConnectorRoute.ts, createConnectorRegistry.ts, and createConnectorAuthenticator.ts, a code change, not configuration. See The gateway.

The permanent ceiling, never claimed, on principle

Directly from 02-REMAINING.md, matching CLAIMS.md §5: unscoped “non-bypassable,” absolute prevention of all unauthorized execution, tamper-proof operation in every environment, guaranteed regulatory compliance, elimination of all software defects. These are not “not yet” items, they’re claims Parmana does not intend to ever make unscoped, because no implementation could honestly back them.