Helix Core Ethos – Runbook v1.0
Helix Core Ethos – Runbook v1.0
Purpose‑Built for the “Two‑Party Approval Flow (TPAF)”
- All steps are deterministic, auditable, and require explicit human confirmation before any irreversible action is taken.*
Model Governance Overview
See: Helix Models Overview for a comparison of model capabilities, parameter sizes, and approved trust levels.
1️⃣ Overview
| Item | Description |
|---|---|
| Runbook ID | HCE‑TPAF‑RB‑001 |
| Version | 1.0 (2025‑09‑15) |
| Effective Date | 2025‑09‑15 |
| Owner | Helix Core Ethos – Governance Team |
| Stakeholders | Product Ops, Security, Compliance, Engineering, Legal, End‑User Support |
| Scope | End‑to‑end execution of a high‑impact intent (e.g., data‑model training, fund transfer, policy change) that requires two‑party (requester + approver) consent before any irreversible effect occurs. |
| Related Docs | • Helix Core Ethos – Principles (TTD‑first, Consent & Least‑Privilege) • API Spec – intent.json‑ld• Smart‑Contract ABI – TPAF.sol• Data‑Retention Profiles (see Appendix A) |
| Assumptions | • All participants have an HSM‑backed signing key registered on the Besu ledger. • Network connectivity to the Besu node is verified (health‑check passed). • The “Intent” payload is human‑readable and stored in an immutable object store (e.g., IPFS, S3 with Object‑Lock). |
| Exclusions | Routine low‑impact intents (Tier 0) that do not require two‑party approval. |
2️⃣ Roles & Responsibilities
| Role | Primary Responsibilities | Required Access |
|---|---|---|
| Requester | Drafts the intent, signs the initial payload, submits to the approval queue. | REQUESTER key, read‑only ledger view.
|
| Approver | Reviews intent, validates compliance, signs to grant consent. | APPROVER key, write‑access to ledger for approval transaction.
|
| Ops Engineer | Executes the runbook, monitors ledger inclusion, triggers downstream actions after confirmation. | Full node admin, CI/CD pipeline trigger. |
| Compliance Officer | Verifies that the intent satisfies all regulatory & policy checks before approval. | Read‑only audit logs, policy‑engine access. |
| Security Analyst | Confirms that HSM keys are healthy, validates cryptographic material, monitors for anomalies. | HSM admin, security monitoring dashboard. |
| Incident Commander (on‑call) | Handles any failure, escalates per the Incident Response Playbook. | Full system access. |
All actions are logged with a tamper‑evident receipt (Merkle proof) that is automatically emailed to the requester, approver, and compliance officer.
3️⃣ Prerequisites
- Infrastructure
- Besu private network node (v22.7.0+) reachable at
https://besu.node.company:8545 - Object store with Object Lock enabled
- CI/CD pipeline with a deploy job to invoke smart contract
- Credentials
- Requester HSM key:
req‑key‑<UUID> - Approver HSM key:
app‑key‑<UUID> - Object store service token (write-once permission)
- Software
node >= 18.0withweb3.jsdocker >= 24jqfor JSON-LD manipulation
- Documentation
- Intent JSON-LD schema (v2.1)
- Compliance checklist (Appendix B)
- Human Confirmation
- Signed statement from Approver confirming understanding of irreversible impact
4️⃣ Procedure – Step-by-Step
All steps are to be executed in order. Any deviation must be logged in Section 7 (Deviation Log).
4.1 Intent Creation (Requester)
Step-by-step actions and expected outputs (see full runbook for exact CLI commands and validations).
4.2 Approver Review & Consent
Verify requester signature → Run checklist → Human confirmation → Sign and archive.
4.3 Ledger Transaction (Ops Engineer)
Submit transaction → Verify receipt → Email parties → Invoke external irreversible API only after all checks.
4.4 Post-Execution: Clean-up & Retention
Archive artifacts → Log retention profile → Schedule purge if applicable → Close run in dashboard.
5️⃣ Monitoring & Alerts
| Metric | Threshold | Alert Destination | Description |
|---|---|---|---|
| Ledger inclusion latency | > 30s/block | Ops Slack #tpa-alerts | Indicates congestion |
| Signature failures | ≥ 1 per run | PagerDuty | Potential key compromise |
| Email delivery failure | > 0 | Compliance email queue | Must resolve before continuing |
| Vault storage error | Any | Ops Email | Prevents data loss |
| Unauthorized access | Any | Security SOC | Detects audit breach |
6️⃣ Failure Handling & Rollback
| Failure Point | Immediate Action | Escalation Path | Evidence to Capture |
|---|---|---|---|
| Schema validation | Abort, return to Requester | None | Validation log |
| Signature failure | Halt, flag for rotation | Security → IC | HSM audit log |
| Checklist ❌ | Reject, notify requester | Compliance → Legal | Checklist snapshot |
| Ledger not mined | Retry x3, then mark Failed | Ops → IC | Tx hash, node logs |
| Email bounce | Re-send alternate channel | Ops → Compliance | SMTP logs |
| External API error | Stop, notify parties | IC → Product | API response |
7️⃣ Deviation Log
| Run ID | Deviation | Reason | Approved By | Date | Mitigation |
|---|---|---|---|---|---|
| uuid‑example‑001 | Increased gas to 250k | Congestion | Security Lead | 2025‑09‑20 | Script updated |
All deviations must be recorded before a run is closed.
8️⃣ Auditing & Evidence
| Artefact | Location | Retention | Access Control |
|---|---|---|---|
| Intent JSON‑LD | S3 (Object-Lock) | 5 yrs | Compliance, Ops |
| Signed Package | S3 (Object-Lock) | 5 yrs | Same |
| Receipt | Besu archive + Vault | 7 yrs | Auditors |
| Emails | Mail archive | 7 yrs | Legal |
| Audit logs | PostgreSQL DB | 10 yrs | RBAC (Auditor) |
All artefacts are hash-linked (Merkle root on-chain).
9️⃣ Post-mortem & Continuous Improvement
- Schedule post-mortem within 48h for failed runs
- Conduct root-cause analysis
- Log action items (tag:
tpa-improvement) - Review metrics quarterly
🔟 Appendices
Appendix A – Data Retention Profiles
| Profile | Description | Min Retention | Max Retention | Delete Trigger |
|---|---|---|---|---|
| low-impact | Non-critical metadata | 30 days | 1 yr | Manual |
| medium-impact | Analytics results | 180 days | 3 yrs | Auto |
| high-impact | Weights, transfers | 5 yrs | 7 yrs | Auto unless legal hold |
| regulatory-hold | Legal/subpoena | Indefinite | Indefinite | Legal override |
Appendix B – Compliance Checklist
All items must be ✅:
- Purpose Limitation
- Data Minimization
- Consent Verification
- Regulatory Mapping
- Risk Severity Rating
- Retention Match
- Security Review
- Audit Trail Integrity
Appendix C – Sample Receipt (JSON-LD)
{
"@context": "https://schema.org/",
"@type": "Receipt",
"identifier": "0xabc123…",
"dateIssued": "2025-09-15T14:23:07Z",
"transactionHash": "0xabc123…",
"requester": "req-key-7f9c‑…",
"approver": "app-key-3a1e‑…",
"signatures": {
"requester": "MEUCIQ…",
"approver": "MEUCIQ…"
},
"merkleProof": {
"root": "0xdef456…",
"path": ["0x01", "0x23", "0x45"]
},
"actionId": "ACT‑2025‑00057",
"status": "completed"
}
✅ Final Checklist Before Closing
- [ ] All signatures verified
- [ ] Ledger receipt status = 1
- [ ] Receipt email sent
- [ ] Human verification recorded
- [ ] External API invoked (post checks only)
- [ ] Artefacts archived
- [ ] Deviation Log completed
Prepared by: Helix Core Ethos – Governance Team Reviewed & Approved: Stephen Hope, Director – 2025‑10‑08
All actions in this runbook are governed by Helix Core Ethos: no hidden training, no dark patterns, no unverifiable claims, and no irreversible actions without confirmed human consent.
