# IHVRK: CAIN-42 integration, Top-100 mapping and commercial evidence

## 1. Placement in the CAIN architecture

IHVRK extends existing moats and is **not** a new moat or a new product listing:
* **Moat 2 (security-context continuity):** the approval binds who (agent, verifier), what (action digest), where
  (resource, tenant, audience) and under which policy version, across the agent → human → executor boundary.
* **Moat 4 (execution provenance):** permit ↔ consumption ↔ execution ↔ ledger record.

Registry (`artifacts/commercial/TOP100_PRODUCT_REGISTRY.json`) entries that overlap, as read on 2026-10-12:

| Rank | Registry entry (source file) | Overlap with IHVRK | Recommendation |
|---|---|---|---|
| 6 | Trust Runtime Kernel (`platform-gateway/cain_trust_kernel.py`, `ActionCapabilityToken`) | single-use capability tokens at the MCPGate boundary | IHVRK permits are the human-approved special case. Keep both; route `REQUIRE_APPROVAL` decisions to IHVRK instead of minting a second token type. |
| 58 | Kernel self-defense (`cain_kernel_self_defense.py`, `DualCustodyEngine`) + `cain_dual_custody_store.py` | two-person approval with nonce consumption in SQLite | **Duplicate concept.** IHVRK break-glass is a stricter variant (role, digest binding, notifier, ledger). Converge on one durable store; do not run two dual-custody stores. |
| – | `platform-gateway/cain_break_glass.py` + `routers/break_glass.py` | break-glass grants with post-event review | **Duplicate concept.** The live one has the review workflow; IHVRK's has action-digest binding. Merge the binding into the live one rather than shipping both. |
| – | `cain/action_commit/approval.py` (`ApprovalBinding`) | action-digest-bound approval | **Duplicate concept**, smaller. It has no nonce consumption, credential status or AAL. Replace with IHVRK's approval object, or wrap it. |
| 8 / 44 / 88 | Independent / clean-room verifiers | evidence verification | IHVRK's `verify_ihvrk_evidence.py` follows the same pattern (no CAIN imports). |
| 18 / 50 | Agent Passport; Capability supply-chain fabric (`cain45/l5/passport.py`, `capability.py`) | agent identity and capability grants | IHVRK consumes capabilities. In integration, its capability issuer key should be the passport/capability fabric's key, not a separate one. |
| 57 / 60 | Authority ledger; replicated governance state machine | ordered, replicated state | candidate linearizable backend for `EpochRegistry` (L-STORE) |
| – | `cain/mcp_proxy.py` (MCPGate) | enforcement boundary for tool calls | integration target (below). Peer finding T-S17-06: no durable per-request ledger today. |
| – | `cain/cain_ebpf_guardian.py`, `cain/ebpf_enforcer.py`, `cain-ebpf/` | kernel enforcement | peer finding T-S17-05: the existing tracepoint program is telemetry; `ebpf_enforcer.py` uses kprobe `bpf_override_return`. IHVRK's LSM design is the cleaner deny path once `bpf` is an active LSM. Pick one. |

Product families from the prompt (Guard, Verify, Comply, Passport, Kernel, Quorum, Sentinel, Frontier): the registry
does not use these as a family field. The mapping above uses the registry's actual entries. IHVRK fits under
Guard/Kernel (enforcement), Verify (evidence verifier), Passport (identity input) and Comply (ledger export as
human-oversight evidence). It needs no Quorum or Frontier component.

## 2. Integration plan (Evolution 2 candidate)

1. **MCPGate `REQUIRE_APPROVAL` → IHVRK.** When the proxy's policy returns `REQUIRE_APPROVAL`, call `propose()`
   with the canonical tool call as the action. The tool runs only through `ExecutionGate.execute` with the returned
   permit. Must not pass through `cain.guard`'s offline-allow fallback (T-S17-03).
2. **One store.** Back `EpochRegistry` and the dual-custody store with the same database. For multi-worker
   gateways on one host the SQLite file already works; for multi-host, use the authority ledger or Postgres with
   serializable transactions behind the same interface.
3. **Verifier channel.** A separate authenticated endpoint for approvals (`channel="VERIFIER"`), never the agent's
   API (I14).
4. **Ledger export.** Checkpoints signed by a key held outside the gateway host, written to the witness log.
5. **Compatibility.** IHVRK changes no existing API. Integration is additive behind a feature flag. Existing
   `REQUIRE_APPROVAL` behaviour stays the default until the flag is on.
6. **Versioning.** Protocol string `ihvrk/1` inside every signed structure, plus domain separators `IHVRK/v1/*`. A
   breaking change gets `ihvrk/2` and new domains, and verifiers accept exactly one version per deployment.

Deployment shapes:
* **Hosted (CAIN Studio):** service + registry + ledger in the gateway; verifier app talks to the approval
  endpoint; checkpoints to the customer.
* **Customer-controlled (MCPGate):** everything on the customer's node; enrollment authority key held by the
  customer.
* **Stand-alone verifier:** `verify_ihvrk_evidence.py` + exported ledger and checkpoints, no other CAIN code.

## 3. Reusable assets (candidates, not established inventions)

| Asset | Implemented where | Evidence |
|---|---|---|
| Action-bound approval protocol (challenge nonce + digest + epoch + policy version) | `service/verification_service.py` | A, B, C, D suites |
| Single-use permit with transactional consumption at the gate | `service/permit_issuer.py`, `nonce/epoch_registry.py` | D1, D3, I9; TLA+ |
| Dual-encoding policy check (Python ≡ Z3, disagreement blocks) | `solver/ihvrk_solver.py` | differential test, H1–H9 |
| Formal invariant set with sensitivity checks | `solver`, `formal` | z3_proofs.json, tlc_summary.json |
| Uncertain-time handling (an expiry inside the clock-uncertainty window → INDETERMINATE) | `policy/authorization_policy.py` | boundary tests |
| Ledger with explained-authorization checks | `ledger/ledger_verifier.py` | G1–G14 |
| cgroup freeze gatekeeper with PID/zombie checks | `runtime/talos_gatekeeper.sh` | F1–F12 |
| Auditor package + stand-alone verifier | `evidence/`, `auditor/` | verify_ihvrk_evidence.py |

**Prior-art and differentiation research plan.** Not done; no novelty claim is made. Before any patent or
differentiation statement, compare against: WebAuthn/FIDO2 transaction confirmation and Secure Payment Confirmation;
PSD2 dynamic linking (approval bound to amount and payee); OAuth 2.0 Rich Authorization Requests and CIBA
(out-of-band user approval); SPIFFE/SPIRE; HashiCorp Vault control groups; AWS IAM Identity Center approvals;
Certificate Transparency and Trillian (checkpointed logs); Teleport and similar access-request workflows; existing
"human-in-the-loop" agent frameworks. Several of these already bind approvals to transaction details, so the
combination with agent capability tokens, a formal model and transactional permits is the most a hypothesis can
rest on. It needs a qualified search.

## 4. Commercial evidence matrix

Kept apart, as the prompt requires. No new dollar figures are introduced here, and existing registered valuation
figures are not restated or changed.

| Category | Content | Evidence |
|---|---|---|
| A Verified implementation assets | the code and tests above, on one node | test_results.json, proofs |
| B Potentially differentiating | dual-encoding policy check; formal + sensitivity evidence packaged for auditors; agent-specific approval binding | none external; hypothesis only |
| C Unvalidated commercial hypotheses | regulated buyers (payments, healthcare, infra changes) want approval evidence for agent actions, e.g. as human-oversight evidence under EU AI Act Art. 14 | none: needs customer interviews |
| D Documented customer value | none for IHVRK | – |
| E Revenue from actual transactions | none attributable to IHVRK (the company-level founder-attested first revenue is not IHVRK revenue) | – |
| F Speculative scenarios | not produced | – |

What would raise buyer confidence, in order: (1) integration into the live MCPGate `REQUIRE_APPROVAL` path; (2) a
verifier app showing a faithful rendering of the action; (3) HSM-backed service keys; (4) the LSM path attached and
tested on a host with `lsm=…,bpf`; (5) an external security review; (6) a pilot customer using it on a real
approval flow. Items 5 and 6 need outside parties.