Mastery: how to sell the FALSEWORK → KEYSTONE → CAIN-42 loop

Purpose: make you the person in the room who can explain, demonstrate, defend and disqualify this product without notes. Read this once end-to-end, then use the drills in Part VI before your first call.

Source of truth: the live routes, HONESTY.md, OFFER.md, PROOF.md, and the code. If this file disagrees with the product, the product wins. Re-check /keystone/stats before quoting a number.

---

Part I — The five mental models

If you remember nothing else, remember these five sentences.

1. The proof gap

Every AI tool can produce a diff. Very few can produce proof that the diff is a fix.

The buyer is not asking for more code. They are asking "how do I know?" You sell the answer to that question.

2. The loop is the product

The detector alone is a scanner. The model alone is a commodity. The cluster alone is a timestamp. The product is the closing loop: detect → act → prove → sign → anchor → export. Sell the loop, not any one part.

3. Independence is the load-bearing property

A test written by the model that wrote the fix is not proof. The reference test must be written by someone else — the customer, their CI, the project, or a different model lab — and it must fail on the old code and pass on the new code. Everything else in the loop exists to protect that one fact.

4. The evidence is falsifiable, not persuasive

You are not asking the buyer to believe a PDF. You are handing them a record they can recompute, a signature they can check against a key they pinned, and a verifier that imports none of your code. The correct sales sentence is:

"You don't have to trust us. Pin the key and re-run it. If we changed one byte, it says TAMPERED OR INVALID."

5. Scope discipline is the product's integrity

One finding. One independent test. One run. It does not prove the rest of the system. The moment you let a buyer believe it proves more, you have sold a certification you cannot deliver. Expertise is knowing exactly where the line is — and saying so before the buyer asks.

---

Part II — The machine

2.1 The data flow

SOURCE CODE
   │
   ▼
FALSEWORK (deterministic) ──► finding (file, line, check, severity, snippet)
   │
   ▼
ACTOR (frontier model, human, or CI) ──► fixed code + actor's own test
   │
   ▼
PROVER (bubblewrap sandbox)
   ├─ reference test on ORIGINAL  → must FAIL
   ├─ reference test on FIXED     → must PASS
   ├─ FALSEWORK re-scan           → finding gone, no new blocking finding
   └─ fix-safety guard            → public API kept, no new deps/capabilities
   │
   ▼
SIGNER (canonical JSON → SHA-256 → Ed25519 → chain)
   │
   ▼
ANCHOR (CAIN-42 PBFT, N=4, f=1, Q=3) ──► quorum receipt
   │
   ▼
EXPORT (record + head + key + verifier + manifest + receipt)

2.2 What each layer is responsible for

2.3 The verdict table (memorize)

2.4 The proof-strength hierarchy

Use this whenever a buyer asks "how independent is it?"

1. Customer / CI acceptance test — strongest. The buyer wrote it; the fixer never saw it.
2. Project's own test suite — independent of the model, but only as strong as the project's tests.
3. Detector-authored oracle — independent of the model, generated by us; a weak oracle is rejected.
4. The model's own test — supporting evidence only; never sufficient.

The product's promise is not "the test is perfect." It is "the test is not the fixer's."

2.5 The evidence object

A record contains: run id, standard, timestamp, path, original code + hash, FALSEWORK findings before, the finding and its fingerprint, the reference test author/lab/origin/hash, the actor and lab, the fixed code + hash, the diff, FALSEWORK findings after, the guard result, test results before/after, the attempt log, the verdict, and the reasons. Then: sequence, previous record hash, record hash, Ed25519 signature, public key.

A bundle contains:

• record-0000.json, record-0001.json — the signed records in chain order;
• head.json — a signed list of exactly which records the bundle holds, in order;
• public_key.json — the issuer's key, for comparison only;
• verify_keystone.py — the standalone verifier, no CAIN imports;
• manifest.json — SHA-256 of every file;
• README.md — the verification instructions;
• quorum-receipt.json — when the run was anchored.

The verification ritual:

unzip -q bundle.zip -d ks && cd ks
KEY=$(curl -s https://cainstudio.online/keystone/public-key | python3 -c 'import json,sys;print(json.load(sys.stdin)["public_key_b64"])')
python3 verify_keystone.py --pinned-pub "$KEY"
# RESULT: ALL RECORDS VALID

Change one byte in a record → RESULT: TAMPERED OR INVALID.

2.6 The trust budget — what the buyer must trust vs. what they can verify

This is the most important table for a technical buyer.

The expert sentence:

"You don't have to trust the operator. You have to trust the test you wrote, the key you pinned, and the code hashes you can recompute. If any of those fail, don't pay."

2.7 What it would take to fake a proof

This is how you answer a security-minded buyer without hand-waving.

1. Forge the signature — need the Ed25519 private key.
2. Change the record — the content hash, the chain link, and the signature all fail.
3. Swap the key inside the bundle — the verifier refuses without a pinned key; a key shipped in the ZIP proves nothing.
4. Fake the cluster receipt — the receipt binds the digest, request id, cluster id, configuration hash, sequence and membership; the QaaS verifier pins the cluster configuration.
5. Corrupt the test — the test hash is in the record; the buyer can compare the test they hold and re-run it.
6. Collude with the cluster — with f=1, one Byzantine replica is tolerated; you would need more than one.
7. Lie at signing time — the operator could sign a record that misstates the test. The defense is the buyer's own re-run: they have the code and the test, and the record tells them exactly what was run. Cryptography prevents undetected tampering; it does not replace the buyer's verification.

---

Part III — The buyer

3.1 Three profiles (from TARGETING.md)

A. The AI vendor in an enterprise security review — highest probability

• 10–300 people, B2B SaaS, shipped an agent or an "AI-powered" feature in the last 12 months.
• A mid-market or enterprise deal is stalled in the buyer's security review.
• The buyer sent a questionnaire or asked "can you prove it?"
• Titles: CTO, VP Engineering, Head of Platform, Head of Security, founder/CEO at a smaller company.

Opening line: "Your buyer asked you to prove the AI feature is real, didn't they?"

B. The team before diligence or a handover

• Raising a seed/A round, being acquired, or inheriting a codebase from a contractor.
• The embarrassing finding is a fabricated metric, not a breach.
• Titles: founder/CEO, CTO, VP Engineering, technical co-founder.

Opening line: "When diligence asks 'is this code real?', what do you send?"

C. The platform team shipping MCP tools or agents

• Public MCP server, agent tool surface, or a coding agent in production.
• The tool definitions are the front door, and nobody reviewed them.
• Titles: platform engineer, AI engineer, security engineer, Head of AI.

Opening line: "Your agent can call tools you haven't reviewed. What does your buyer get when they ask?"

3.2 Triggers (a trigger beats a title)

• a funding announcement in the last 60 days;
• a launch post for an agent or an "AI-powered" feature;
• a job post for an AI engineer, AI security engineer, or platform engineer;
• a public MCP server or public agent tool list;
• a post about a security questionnaire, procurement, or an enterprise customer;
• a post about Copilot, Cursor, Claude Code, or "vibe coding";
• a handover post ("excited to join as CTO");
• a public incident or near-miss in their category (do not imply it happened to them).

3.3 Qualification — ask before the call

1. What did the buyer actually ask for — a questionnaire, a pen-test report, or "show me it is fixed"?
2. Is the code Python? (If no, stop for the code proof.)
3. How big is the repo, roughly?
4. Is there a deadline? (A real date, not "soon".)
5. Who signs, and what is the payment process?

If the answers are "not Python", "no deadline", and "just exploring", send the sample bundle and stop.

3.4 Disqualify early (this protects the price and the calendar)

• They want a pen test, a SOC 2, or a certification. We do not sell those.
• They want a guarantee that their system is safe. We do not sell that.
• They want a full platform or an enterprise subscription. That is not the 24-hour offer.
• They cannot share code or a module. Without code, there is no loop.
• They want the report before paying. The sample report is public; the work is the fee.
• They want us to name a customer without written permission.

---

Part IV — The sale

4.1 The 30-second version

"Your AI tool says it fixed the bug. Your buyer says prove it. We run a deterministic detector, fix the finding, prove it with a test the model didn't write, sign the record, notarize it on a 4-replica Byzantine cluster, and hand you a verifier that imports none of our code. $500, one Python module, 48 hours."

4.2 The 2-minute version

Add the six stages and one honest limit. End with the tamper demo:

"Download the bundle, pin the key, run the verifier. If we changed one byte, it says TAMPERED OR INVALID."

4.3 The 10-minute version

Use Part II. At minute 6, run the live demo (Part V). At minute 8, state the limits before they ask. At minute 9, ask for the file and the test.

4.4 Discovery script (5 questions)

1. "What is the finding, in one sentence?"
2. "Who is asking for proof, and what would satisfy them?"
3. "Do you have a test that should fail today and pass when it's fixed?"
4. "Is it Python? One module or a repo?"
5. "What is the deadline?"

Then: "Send me the file and the test. I'll tell you in 20 minutes whether the detector can see it. If it can, the pilot is $500 and 48 hours. If it can't, I'll tell you and we won't take the money."

4.5 Demo script (5 minutes)

1. Open https://cainstudio.online/linkedin.html — let the explainer play or skip to the proof.
2. Free scan: POST /keystone/scan-source with their snippet. Show the grade and the line.
3. Live ledger: https://cainstudio.online/keystone/stats — 9 records, 6 VERIFIED_FIX, 2 NOT_VERIFIED, 1 NOTHING_TO_FIX. Say: "The failures are still in the ledger. That's the point."
4. Download the anchored bundle: run ksh-20261105T112903Z-9befe643.
5. Verify with the pinned key → RESULT: ALL RECORDS VALID.
6. Tamper with one byte → RESULT: TAMPERED OR INVALID.
7. Cluster: https://cainstudio.online/api/v1/quorum/status → N=4, f=1, quorum 3.
8. Close: "Send me the file and the test. $500, 48 hours. If we can't produce a signed record, refunded."

4.6 Pricing conversation

• $500 is a pilot, not a discount. It buys a real run, a real record, a real verifier.
• $1,500 is the audit: one repo, up to 5,000 files, 48 hours, $750 deposit.
• Fix + Prove attaches at $500 / $1,500 / $2,500 per finding.
• Deep/diligence: $3,500 / $6,000.
• Never discount the proof. Reduce scope instead: one module instead of a repo, one finding instead of five.
• The alternative is not "free"; it is another week of engineering, a stalled deal, or a $10k+ audit.

4.7 Objection matrix

4.8 Close

"Send me the module and the test. I'll run the detector first and tell you whether it can see the defect. If it can, $500 and 48 hours. If it can't, I'll tell you and we won't take the money."

4.9 Handoff after payment

Point them to https://cainstudio.online/loop-paid.html:

• Pilot: the file + the finding (or the test they want proved).
• Audit: read-only repo access + deadline + the buyer question.

4.10 Delivery email (template)

Subject: Your PROOFLOOP proof — run <id>, signed and anchored

Attached: evidence.zip.

Verify on your machine with the key you pin from
https://cainstudio.online/keystone/public-key:

  unzip -q evidence.zip -d ks && cd ks
  KEY=$(curl -s https://cainstudio.online/keystone/public-key | python3 -c 'import json,sys;print(json.load(sys.stdin)["public_key_b64"])')
  python3 verify_keystone.py --pinned-pub "$KEY"

Expected: RESULT: ALL RECORDS VALID.
If one byte changed: RESULT: TAMPERED OR INVALID.

What this proves: this finding, against this test, on this code.
What it does not prove: the rest of your system, your deployment, or your test suite.
If it does not verify on your machine, tell me within 48 hours. The balance is not billed.

---

Part V — The live assets and what to show

Numbers to re-check before quoting: /keystone/stats (records, verdicts, standards), /keystone/ledger/verify (chain valid), /api/v1/quorum/status (cluster health). Do not quote a remembered number; open the route.

---

Part VI — Drills (do these before your first call)

6.1 Flashcards — cover the right column

6.2 The 60-second teach-back

Explain to a non-technical friend, out loud, without notes:

"AI writes code very fast, but it can't prove the code works. We find the fake part, fix it, and prove the fix with a test the AI didn't write. Then we sign the proof and stamp it on a independent cluster. The buyer can check it themselves, without us. It costs $500 and takes 48 hours."

If you stumble, you are not ready. Repeat until it is smooth.

6.3 The 10-minute technical teach-back

Draw the six-stage diagram from memory. For each stage, say:

• what it consumes,
• what it produces,
• what it can fail,
• what it proves,
• what it does not prove.

6.4 The disqualification drill

Read these aloud and practice saying no:

• "Can you do a pen test?" → "No. We prove a fix for a finding; we don't do pen tests."
• "Can you give us SOC 2?" → "No. We have no certification. What we have is evidence you can re-run."
• "Can you guarantee our system is safe?" → "No. We prove one finding against one test."
• "Can you do it for free first?" → "The scan is free. The proof is the paid work. The sample bundle is free to verify."
• "Can you name a customer?" → "No. No customer has agreed to be named."

6.5 Mock call rubric (score yourself 1–5)

1. Did you open with the buyer's sentence, not the architecture?
2. Did you ask the five qualification questions before pitching?
3. Did you show the live ledger and the tamper demo?
4. Did you state one honest limit before the buyer asked?
5. Did you ask for the file and the test, with a clear price and timeline?
6. Did you avoid every forbidden claim?
7. Did you disqualify if it was not Python or had no finding?
8. Did you leave the buyer with one next action, not three?

A 9/10 call has all eight, plus the buyer saying "send me the link."

6.6 The 7-day mastery plan

---

Part VII — The one-page cheat sheet

One-liner: A signed proof your buyer can re-run.

The loop: DETECT → ACT → PROVE → SIGN → ANCHOR → EXPORT.

The rule: the reference test fails on the old code and passes on the new code.

The evidence: Ed25519 + SHA-256 + hash chain + 4-replica PBFT quorum (3 of 4) + offline verifier.

The limit: one finding, one test, one scope. 3 of 12 on the fresh blind set. No SOC 2, no ISO, no third-party audit.

The offer: $500 pilot, one Python module, 48 hours. $1,500 audit, one repo, 48 hours, $750 deposit.

The close: "Send me the file and the test. $500, 48 hours. If we can't produce a signed record, refunded."

The trust sentence: "You don't have to trust us. Pin the key and re-run it. If we changed one byte, it says TAMPERED OR INVALID."

The team: Vincent Noriega (founder), Lena Noriega, Monica Diaz. FIRME AI CORPORATION.

---

Appendix — Market context you can use (third-party signals, not our data)

Use these only as context, never as proof of our product:

• 83% of organizations plan agentic AI; only 24% have controls (Cisco).
• 88% of organizations had an AI-agent incident (Gravitee 2026).
• Public unauthenticated MCP servers grew from 492 to 1,467 (Trend Micro).
• The AI-security market is projected at ~$7.44B by 2030.

The buyer's world is moving faster than their ability to prove what the agents did. That is the gap you sell into.

---

Appendix — The three sentences that must never leave your mouth

1. "It's certified." (It is not.)
2. "It proves your system is safe." (It proves one finding.)
3. "Only we do this." (Unprovable, and the repo forbids it.)

Replace them with:

1. "It's evidence you can re-run."
2. "It proves one finding against one independent test."
3. "Most tools stop at the diff. This loop doesn't."