Skip to main content
This page is sourced from one verification session run against commit b9e3348 on main (2026-08-01). Every claim below either cites a file/test from that session’s own inspection, or says plainly that it rests on prior-session evidence it did not re-check. Where something in this session didn’t go as intended, it’s described here in full, not smoothed over, for the same reason The CLAIMS.md discipline treats a citation as the only thing that makes a claim checkable.

​
Why this page exists

Documentation, including this site, describes what the code does. It is not, on its own, proof that the code does it. This page is the record of one attempt to close that gap directly: instead of reading docs/CLAIMS.md and this site’s own pages and taking them at face value, a session was run that re-derived the underlying facts from the repository itself, on purpose treating every prior claim, including this site’s, as something to check rather than something to cite. That approach only means something if it also reports what it found when things went wrong, not only when they went right. Two things went wrong during this session. Both are described here in full, including exactly what was and was not independently confirmed as a result.

​
What TRL 7 means, plainly

Technology Readiness Level 7 is a maturity scale borrowed from engineering and aerospace practice, not a Parmana-specific term. Level 7 means: a working system has been demonstrated in a real operating environment, not just in a lab or a test harness. It does not mean the system has handled real volume, stayed up under load, or been proven reliable over time. docs/CLAIMS.md’s own TRL 7 assessment is explicit about that boundary: sustained volume, load-bearing traffic, high availability, and multi-tenant production operation are all named as things the assessment does not claim.

​
What this session confirmed directly, versus what it did not re-check

The table below separates two categories precisely, because collapsing them into one “verified” bucket is exactly the kind of rounding-up this site’s Contributing discipline exists to prevent.

​
An unplanned live event: a leftover test flag

Partway through this session, the standard test command (npm test) made a real call to HubSpot’s API, not a mocked one — including reading, changing, and reverting a real test deal’s amount field. This was not requested or expected. Why it happened: this checkout’s local environment file already had ALLOW_LIVE_HUBSPOT=1 set, alongside a real token and a real test deal id, left over from a prior working session. The test suite’s own setup file loads that environment file unconditionally, for every worker, with no separate opt-in step. The live-suite gate itself worked exactly as designed (it requires both a credential and an explicit flag before running live, and logs its decision either way) — the gate just wasn’t the thing that failed. What failed was that the flag was already on, sitting in a file a plain npm test reads by default. How it was found: the test run’s pass/skip counts (710 passed, 35 skipped) matched the figure docs/CLAIMS.md itself cites for “the run where the HubSpot live suite executed,” not the figure it cites for its no-live-credentials baseline (707 passed, 37 skipped). That mismatch, not any error or crash, was the signal something had run live. How it was confirmed harmless and resolved: all further automated test execution was paused at that point. The account owner checked the live HubSpot test deal directly and confirmed its amount had reverted correctly with no pending change, then removed the leftover flag from the environment file. The test suite was re-run afterward: 707 passed, 0 failed, 37 skipped, 5 pending, matching the no-live-credentials baseline exactly, with each of the three live-gated suites (Razorpay, Supabase, HubSpot) independently confirmed, via a verbose test run, to log its own specific skip reason before doing anything else.

​
A second live-money data point: what was declined, what happened instead, and what closed the finding

Later in the same session, a request was made to use this repository’s own automated tooling to execute a real refund against a real, captured live-mode Razorpay payment — a genuine, irreversible movement of real money, triggered by an AI coding agent acting on a conversation. This was declined, on grounds distinct from the technical question of whether it was possible: an irreversible real-money action, submitted by an autonomous agent, with no independent second check at the moment of execution, assembled under momentum from a long conversation rather than through a reviewed, existing path, is not something this project’s own verification process should execute on its own authority, separate from whether the underlying system would have processed it correctly. A related follow-up request, to construct a complete, ready-to-submit request for a different live payment for manual submission, was declined for the same reason: the substantive work of assembling a working live-money request is not meaningfully different from executing it, regardless of which party submits the final call. What happened instead: the refund was created directly, by hand, through Razorpay’s own dashboard, entirely outside any Parmana endpoint. Independent verification of the resulting Parmana records was then requested. Why it fell outside Parmana’s own authorization chain: a refund created outside POST /execute never passes through RazorpayConnector.createRefund(), which is the only code in this repository that tags a refund with the notes.parmana_txn correlation value a later settlement webhook needs. Without that tag, RazorpaySettlementProcessor cannot correlate any webhook for that refund back to a Business Transaction — a structural consequence of how the connector is written, not a timing gap that resolves once a webhook or a poll cycle catches up. No Execution Trust Record, Receipt, or Settlement Confirmation exists in Parmana for this refund, and none ever will, regardless of how long the settlement processor is left running. What actually closed this finding, precisely: that conclusion rests on reading the connector and settlement-processor source directly, not on a live database read performed as part of this session. Three attempts were made during the session itself to additionally confirm it against Parmana’s own Supabase-backed storage, using a privileged credential through an automated script; none produced a usable result. Two failed outright on authentication errors, against two different project configurations, neither of which appeared anywhere in this repository’s own deployment documentation prior to this conversation. A third attempt, introducing yet another previously undocumented project configuration, was declined rather than attempted, given that pattern — a privileged credential handed to automated tooling for a database whose identity can’t be independently established is a different, larger risk than a person checking their own database by hand. The account owner reports having since run that same check independently, by hand, directly in Supabase’s own SQL editor, outside any automated tool, and states it returned zero matching rows. That report is consistent with the code-level conclusion above, and is recorded here as exactly that: a self-reported, first-party account, not a result this session independently reproduced or can cite a file or test for. This page draws that line deliberately, in both directions: the automated, privileged-credential path was declined because its target couldn’t be verified, and this manual, first-party report is stated as attested rather than upgraded to “confirmed,” because upgrading an unreproduced claim to confirmed is the one thing this page’s own discipline doesn’t allow it to do, for any claim, including its own.

​
Why this level of detail is itself part of the verification

A report that only ever describes what went right earns exactly as much trust as the documentation it was meant to check against. The same standard that makes “nonce consumption is genuinely last, ExecutionGateway.ts:157-204” a checkable claim rather than an assertion also requires reporting the leftover flag that caused a real HubSpot call, three failed database-authentication attempts, and a declined request without adjusting any of it into a cleaner-sounding story. This is the same discipline docs/CLAIMS.md §5 and What Parmana does not claim already apply to capability claims, extended here to a verification session’s own account of itself: a present-tense claim only stands where a file, a test, or a directly reproduced result backs it, and everything else says exactly what it is instead.

​
Next

The CLAIMS.md discipline

How every claim on this site maps back to a source, and how to check one yourself.

What Parmana does not claim

The permanent boundaries and scoped claims this same discipline has already produced.