GAMP 5 Test Authority — How the Cell Proves It Works¶

One-sentence summary: the cell is qualified to a regulated-industry standard called GAMP 5 by running four stages of self-tests on every boot, and writing signed receipts so a regulator can verify it years later.

Start with this picture¶

Imagine you build a car. You can drive it around the block. It seems to work. Should the government let you sell it?

Most countries say no. Before you can sell a car, you have to qualify it through specific tests: brake distance from 60 mph, crash resistance at 35 mph, emissions, fuel economy. Each test is described in a public document. Each test gets a written certificate from a regulator. If the car fails a test, you cannot sell it.

The same logic applies to software in regulated industries — pharmaceuticals, finance, medical devices, anywhere a software bug could hurt people or money. The standard is called GAMP 5 (Good Automated Manufacturing Practice, version 5). It defines how custom software gets qualified.

GAMP 5 splits qualification into four stages: IQ, OQ, PQ, MQ.

The Franklin cell is qualified to GAMP 5 Category 5 (the most stringent — bespoke software). It carries its own qualification stack inside itself.

The four stages¶

IQ — Installation Qualification¶

The question: is the cell installed correctly?

IQ checks things like: - Did all the database migrations run successfully? - Are the substrate tables present and in the right shape? - Is the keystore in place? - Is the cell's identity file written? - Are the append-only triggers active? - Is the substrate's locus (this specific Mac) recorded? - Is the audit log capturing violations correctly?

There are 7 IQ tests (IQ-001 through IQ-007). Each one runs at boot. Each one writes a signed receipt to the substrate. If any one fails, the cell cannot proceed.

OQ — Operational Qualification¶

The question: does the cell operate correctly?

OQ checks things like: - Does the narrator catalog have all the meaning atoms it should? - Are the vQbit 8-axis measurements giving sane values? - Does the Klein topology verifier confirm the cell can't lie? - Are the 25 fallacy detectors all loaded? - Is the discipline framework sound? - Are the alignment claims substrate-warranted? - Is the alignment system free of LLM influence?

There are 7 OQ tests (OQ-001 through OQ-007). They run on every boot. Each writes a signed receipt.

PQ — Performance Qualification¶

The question: does the cell perform under load, over time?

PQ checks things like: - Is the gate latency under the threshold? - Is the frame chain unbroken? - Is the NATS proxy responsive? - Is the apply log up to date? - Does the catalog coverage match expectations? - Is the causal chain reconstructible? - Do signature verifications all pass?

There are 7 PQ tests (PQ-001 through PQ-007). Some require accumulated activity to pass — they hold at PENDING_OBSERVATION until enough data has been gathered to make a statistical claim. The licensing PQ, for example, needs at least 7 executed grants and 30 treasury snapshots before it switches to PASS.

MQ — Constitutional / Manifold Qualification¶

The question: is the cell constitutionally coherent?

MQ is the most unusual stage. It checks the things that make Franklin different from a normal app: - Is the catalog complete and signed? - Are turn-closure receipts being written on every walk? - Are the structural disciplines holding? - Is the fallacy family taxonomy intact? - Is the wiki being rendered from the substrate (not from a separate doc system)? - Is the cell keystore properly migrated? - Is the alignment system genuinely LLM-free?

There are 7 MQ tests, each a constitutional invariant.

The total: 156 tests¶

Each of the four stages has 7 tests in its primary catalog (28). Each test runs against multiple objects (algorithms, plants, protocols, scenarios). The full qualification stack works out to 156 individual test invocations that run on every boot.

156 is not a magic number. It is the count of (test) × (object) pairs the cell tracks. If you add a new algorithm to the quantum catalog, the count goes up. The substrate enforces this — there is a constitutional invariant that says SUM(algorithm_count WHERE domain LIKE 'quantum%') == 19. If somebody tries to add a 20th algorithm without going through the full qualification, the invariant fires and the cell refuses the change.

The 5-context quorum signing¶

Every qualification receipt is signed by 5 contexts inside the cell:

narrator_authoring_context — the context that authored the test claim.
gate_authoring_context — the context that authored the test gate.
pq_validation_context — the context that ran the test.
wiki_documentation_context — the context that documented the test.
turn_sealer_context — the context that sealed the receipt.

All five must sign for a receipt to count. This is the cell's internal "court of witnesses" — five different actors, each with their own role, all agreeing that the receipt is valid. If any of them refuse to sign, the receipt is not written. The cell will not move forward.

Why this matters¶

In most software, "testing" is something the developer did once before shipping. After that, users trust that the tests were run.

GAMP 5 Category 5 doesn't allow that. The tests have to be part of the running system. They have to fire on every boot. They have to leave a signed audit trail. A regulator must be able to pull the audit trail years later and verify it.

Franklin does this every boot. The receipts are append-only in the substrate. They are signed by quorum. They survive forever. If a regulator wants to know whether the cell was qualified on a specific day in 2027, they pull the substrate file from that day, run SELECT * FROM qualification_receipts WHERE booted_at_iso LIKE '2027-04-15%';, and read the answer.

This is what "regulated AI deployment should look like" means. Not promises. Receipts.

The four terminal states a test can have¶

Each qualification test ends in one of four terminal states (the same four states the cell itself can be in), plus one for honest waiting:

State	Plain meaning
`CALORIE`	The test passed. The thing it checked is real and trustworthy.
`CURE`	The test is partly passing. Some criteria met, others are converging.
`REFUSED`	The test was deliberately refused by a constitutional invariant.
`BLOCKED`	The test cannot proceed — something is broken upstream.
`PENDING_OBSERVATION`	The test cannot decide yet — needs more accumulated data.

A test in PENDING_OBSERVATION is not failing. It is honest. "I cannot make this performance claim with one boot of data. Come back when I have thirty days." The cell prefers honest "I don't know yet" to a confident wrong answer.

The validation chain¶

Each test receipt links to the previous receipt for the same test ID. This is called the validation chain. Query the chain for IQ-001 from oldest to newest and you see a continuous history of the cell's installation state over its entire lifetime.

If the chain ever breaks — if you query for IQ-001 and find a gap — you know somebody tried to tamper with the substrate. The cell's append-only triggers make this near impossible without deleting the entire file, but the chain is the second layer of defense.

The validation chain is counted in boot recall — the cell announces the total ("I hold 156 GAMP 5 validation receipts") as part of its identity statement.

Where to read the actual receipts¶

If you have the cell installed:

sqlite3 ~/Library/Application\ Support/GaiaFTCL/substrate.sqlite

-- All qualification receipts (newest first)
SELECT test_id, terminal_state, booted_at_iso, signed_by_quorum
  FROM qualification_receipts
  ORDER BY booted_at_iso DESC
  LIMIT 20;

-- Specifically the licensing PQ over time
SELECT validation_id, terminal_state, booted_at_iso
  FROM c4_validation_receipts
  WHERE validation_id LIKE 'GFTCL-VAL-LICENSING%'
  ORDER BY booted_at_iso;

-- Boot recalls with their validation receipt count
SELECT boot_index, validation_receipts_total, booted_at_iso
  FROM cell_boot_recall
  ORDER BY boot_index;

Open the substrate. Read the rows. That is the qualification stack.