Files
vm-core/docs/VAULTMESH-SENTINEL-GTM-BATTLECARD.md
2025-12-27 00:10:32 +00:00

3.9 KiB
Raw Blame History

VaultMesh Sentinel — Go-To-Market Battlecard (v1)

What we are

VaultMesh Sentinel is the forensic continuity layer for autonomous infrastructure.

Sentinel makes systems defensible after failure, not merely secure during operation, by emitting offline-verifiable evidence of:

  • what happened
  • what was attempted and denied (Proof of Restraint)
  • who/what had authority
  • what corruption/tamper was detected

Who we sell to (ICP)

Primary buyers:

  • Space agencies & contractors (satellites, on-orbit servicing, lunar infrastructure)
  • Critical IoT / OT operators (energy grids, pipelines, factories)
  • Defense & national infrastructure vendors

Buyer personas:

  • Program managers (mission liability)
  • Security / safety leads (post-incident accountability)
  • Compliance & legal (audit survival)
  • Insurers (claim defensibility)

The problem they already feel

  • Automation is increasing faster than accountability.
  • Systems operate offline, autonomous, and under coercion.
  • After incidents, there is blame without proof; logs without integrity; narratives instead of evidence.

Our wedge (why we win first)

Proof of Restraint

Sentinel produces auditable evidence not only of actions executed, but of actions considered and safely denied, with:

  • denial reason (bounded + schematized)
  • the exact operation that would have occurred (op + digest)
  • any containment applied (scope narrowing)

What Sentinel actually ships (v1)

  • Action gating: intent → allow/deny → effect
  • Append-only receipts + deterministic Merkle roots
  • ShadowReceipts on denial (no silent drops)
  • Corruption/tamper receipts and degraded-mode containment (authority can only narrow)
  • Offline export bundles (seals) + offline verifier
  • Archaeology drill as onboarding requirement

The one-line pitch

“VaultMesh Sentinel is the black box recorder for autonomous infrastructure — it proves what happened, what was denied, and why, even years after failure.”

Why now

  • Automation is unavoidable (space latency, industrial scale)
  • Regulation is tightening (NIS2 / CRA pressures)
  • Insurance is demanding evidence, not promises
  • Incidents are becoming political and international, not technical

Competitive landscape (why others lose)

Competitor type Why they fail
SIEM / logging Logs can be deleted, forged, coerced, or re-framed
Cloud governance Assumes connectivity and a trusted control plane
Blockchains Assumes liveness/consensus and pushes complexity into ops
Safety systems Enforce rules but dont prove restraint
Dashboards Disappear after the incident

Sentinel assumes the incident already happened.

Proof artifacts (what we can hand an auditor)

Typical export bundle contains:

  • ROOT.current.txt (root + seq + timestamp + algorithm identifiers)
  • receipts.jsonl or a SQLite export covering the range
  • seal.json (bundle metadata + ranges + root commitments)
  • integrity.json (hashes of included files)
  • verifier_manifest.json (expected tool versions/checksums)

Pricing anchors (not promises)

Deployment licensing:

  • Space / defense: $250k $5M per system
  • Critical IoT / OT: $50k $500k per site

Recurring:

  • Long-term support & verification tooling
  • Compliance & evidence export packages

First killer demo (closes deals)

“The Black Box That Refused”

  1. Autonomous system runs offline.
  2. Unsafe command is issued.
  3. Sentinel denies it (ShadowReceipt emitted).
  4. System continues safely.
  5. Later, an auditor receives a proof bundle and verifies it offline.

Outcome: clear authority trail, provable restraint, zero ambiguity.

Expansion path

  1. Start as single-sovereign Sentinel (isolation-correct)
  2. Add continuous invariant verification + drift containment
  3. Optional federation for cross-witnessing (witness augmentation, not correctness)
  4. Become a recognized evidence standard for autonomous operations