← ethraeon.systems

1. What Is Deployed

1.1 Live Surfaces (Cloudflare Pages)

42 HTML surfaces deployed at ethraeon.systems via Cloudflare Pages project ethraeon-demos.

Surface	Path	Purpose
Landing	/	Primary entry
Executive	/executive.html	Executive summary
Capital	/capital/	Capital raise surface
Capital (legacy)	/capital.html	Capital overview
Demo	/demo/	Live governance demo
Lyra	/lyra/	Lyra system interface
Investor	/investor/	Investor materials
Status	/status/	Health lock (auto-refreshing)
Trust	/trust/	Trust snapshot surface
Sovereign Metal	/sovereign-metal/	Sovereign metal surface
Metrics	/metrics/	System metrics dashboard
Control	/control/	Master control surface
Meeting	/meeting/	Meeting mode (capital/technical)
Share	/share/	Distribution index (public/private)
Data Room	/data-room/	Due diligence data room
Brief	/brief/	System brief
Enterprise	/enterprise.html	Enterprise contact
Wall	/wall.html	IP wall
Architecture	/architecture.html	System architecture
Compliance	/compliance.html	Compliance overview
Close Proof	/close_proof.html	Close execution proof
Demo Delta	/demo/governance_delta.html	Governance delta demo

Plus 20 additional surfaces: authority, complexity, moat, why_now, scale_authorized, capital_institutional, capital_readiness, start, whats_live, investor-room, investor_room/, contact, system_map, runtime_status, health, status (legacy), system_status, enterprise_contact_gate, data-room/assurance.

1.2 Cloudflare Workers

Worker	File	Purpose
CDASA Ingestion	deploy/workers/cdasa_worker.js	Signal ingestion + KV storage
Demo API	deploy/workers/demo_api.js	Demo data API
Lyra Worker	deploy/workers/lyra_worker.js	Lyra backend
Media Router	deploy/workers/media_router.js	Media asset routing

Configuration: deploy/workers/wrangler.toml

1.3 App Runtimes (Python)

System	Directory	Ports	Runtime
TRACELET 1.1+EDG	app/tracelet/	8001 (Flask), 9009 (FastAPI)	Python
ROSETTA 1.0.0	app/rosetta/	5002 (Flask unified), 8002-8004	Python
DELTASUM 2.0.1	app/deltasum/	Library (no port)	Python
KAIROS 1.0	app/kairos/	Library (no port)	Python
AURIX	app/aurix/	--	Python
CORIX	app/corix/	--	Python
ETH001	app/eth001/	--	Python
FACTPULSE	app/factpulse/	--	Python
LYRA	app/lyra/	--	Python

2. What Runs Where

2.1 Cloudflare Pages

• Project: ethraeon-demos
• Custom domains: ethraeon.systems, www.ethraeon.systems
• Build command: bash ops/deploy/cloudflare_pages_build.sh
• Output directory: deploy/cloudflare_pages
• Deploy trigger: Push to main via GitHub Actions (cf_pages_deploy.yml)
• Auth: Token-only (CF_API_TOKEN, scoped to Pages deploy)

All HTML, JSON, CSS, and static assets are pre-assembled in deploy/cloudflare_pages/. No compilation. No bundler. The build script validates and stamps.

2.2 Cloudflare Workers

Deployed separately via Wrangler. Each worker has its own KV bindings and routes.

2.3 App Wrappers (Python)

TRACELET and ROSETTA expose HTTP APIs. DELTASUM and KAIROS are libraries imported by other systems. Currently run locally or on VPS.

2.4 VPS (Iceland, 1984.is)

Status: Quarantined. Zero DNS records point to it. Recovery requires CEO authorization.

3. Governance

3.1 Founder's Law

If it exists conceptually, it must exist operationally. If it can be instrumented, it is instrumented now. No "not yet," no "[Content pending]," no "designed but not deployed." Ship. Always.

3.2 Constitutional Governance

Highest governance tier. Non-negotiable rules:

1. FAIL-CLOSED - When in doubt, do nothing. Never assume.
2. EVIDENCE-REQUIRED - Every meaningful change produces a traceable artifact.
3. NO FABRICATION - If you don't have real data, mark it HOLD or unknown.
4. NO DOWNGRADING - IP status, valuations, and roles only increase.

3.3 Authority Levels

Code	Role	Scope
Level 1	S. Jason Prohaska, CEO	Full constitutional override
Level 2	CFO	Capital and audit authority
Level 3	Technical Lead	/app and /ops authority
Level 4	Operator	Execute-only, no override

3.4 Mutation Protocol

Every change to committed code follows this sequence:

1. Directive issued (Founder authority)
2. Changes implemented with evidence artifacts
3. Validation gates pass (canon pack, pytest, build)
4. Seal files created (JSON + MD) in ops/runtime/
5. Commit with directive reference
6. Push to main

3.5 Evidence Chain

• evidence/chain.jsonl - append-only hash chain
• evidence/directives/ - directive documents (0NNN_TITLE.md)
• evidence/receipts/ - SHA inventories matching directive numbers
• evidence/runtime/ - runtime state reports

Each chain entry links to its predecessor via prev_hash, forming a cryptographic chain.

3.6 Promotion-Only Policy

Per policy/PROMOTION_ONLY.yaml:

• Never delete - only add or deprecate
• Retire by pointer: status: deprecated, superseded_by: /new/path
• Lifecycle: active → deprecated → retired

4. Validation Gates

Three validators must pass before every commit:

4.1 Canon Pack Validation

node tools/validate_canon_pack.js

Scans production code for forbidden patterns. Any match is a hard failure.

4.2 Test Suite

python3 -m pytest -q

6 test files covering: DELTASUM hash verification, ROSETTA engine initialization, TRACELET EDG node emission, KAIROS ethics audit pipeline, break-glass authorization, nonce verification, expiry enforcement, spoofing detection, contact/revenue flow, reproducibility lock.

4.3 Build Verification

bash ops/deploy/cloudflare_pages_build.sh

The build script:

1. Generates runtime_index.json from repo state
2. Generates share_manifest.json with SHA-256 hashes
3. Generates capital_snapshot.json from runtime logs
4. Injects BUILD_TRACELOCK (commit SHA + timestamp) into all HTML files
5. Verifies injection in required files (index.html, capital/index.html, executive.html)
6. Validates all required static files exist
7. Restores placeholders for local dev (if not in CF Pages environment)
8. Verifies capital_snapshot.json commit_sha matches HEAD

5. How to Build and Deploy

5.1 Local Validation

cd ethraeon-canonical-app
node tools/validate_canon_pack.js # Canon artifact validation
python3 -m pytest -q # Unit tests
bash ops/deploy/cloudflare_pages_build.sh # Build verification

All three must exit 0.

5.2 Deploy to Production

Push to main. GitHub Actions handles the rest:

git add <files>
git commit -m "DIRECTIVE_NUMBER: DESCRIPTION"
git push origin main

5.3 Generate Artifacts

# Runtime index
python3 tools/generate_runtime_index.py

# Share manifest
python3 tools/generate_share_manifest.py

# Board packet PDF
python3 tools/generate_board_packet.py

# Engineering Guide PDF
python3 tools/generate_engineering_bible.py

6. How to Verify

6.1 Status Surface

https://ethraeon.ai/status/ - Auto-refreshing health lock. Shows commit SHA, build timestamp, system state.

6.2 Runtime Index

https://ethraeon.ai/runtime_index.json - Machine-readable system state: HEAD SHA, branch, governance tier, directives sealed, HTML surfaces, patent totals.

6.3 Share Manifest

https://ethraeon.ai/share_manifest.json - SHA-256 hashes for all distribution artifacts.

6.4 Hash Verification

sha256sum <file>
# Compare against share_manifest.json entry

DELTASUM runtime verifies canonical data files at load time. Hash mismatch = runtime refuses to load.

6.5 Evidence Chain

# View latest evidence entries
tail -5 evidence/chain.jsonl | python3 -m json.tool

# Verify chain integrity
python3 -c "
import json, hashlib
entries = [json.loads(l) for l in open('evidence/chain.jsonl')]
for i, e in enumerate(entries):
 if i > 0:
 assert e['prev_hash'] == entries[i-1]['chain_hash']
print(f'Chain intact: {len(entries)} entries')
"

7. How to Extend

7.1 Add a New Surface

1. Create HTML file in deploy/cloudflare_pages/<name>/index.html
2. Add route to deploy/cloudflare_pages/_redirects
3. Add entry to deploy/cloudflare_pages/sitemap.xml
4. Run python3 tools/generate_runtime_index.py to update counts
5. Run build script to verify
6. Commit with directive reference

7.2 Add a New Worker

1. Create JS file in deploy/workers/<name>.js
2. Add configuration to deploy/workers/wrangler.toml
3. Deploy via Wrangler CLI
4. Document in this file

7.3 Add Executive Documents

1. Place .md file in docs/executive/
2. Run python3 tools/generate_board_packet.py
3. Run python3 tools/generate_share_manifest.py to hash
4. Commit with directive reference

7.4 Add Engineering Documents

1. Place file in docs/engineering/
2. Run python3 tools/generate_share_manifest.py to hash
3. Commit with directive reference

8. Core Systems Detail

8.1 TRACELET 1.1+EDG

Orchestration engine with Evidence Graph. Two API surfaces:

FastAPI (port 9009) - Primary runtime (app/tracelet/cipher_edg_main.py):

• POST /cipher/query - Query with constitutional compliance
• POST /cipher/store - Store memory entry
• GET /edg/verify?hash= - Verify EDG hash
• GET /edg/node/{hash} - Retrieve EDG node
• POST /edg/emit - Emit new EDG node
• GET /edg/chain - List all EDG hashes
• GET /health - Health check

EDG Node Schema:

{
 "agent": "AGENT_NAME",
 "task": { "type": "action_type", "content": "description" },
 "result": { "status": "success|failure", "details": "..." },
 "timestamp": "ISO-8601",
 "tracelet_version": "1.1.0"
}

8.2 ROSETTA Triad

Patent implementation engines:

Engine	Patent	USPTO	Port
Harmonic Substrate Foundation	#8	Provisional (US, filed)	8002
Recursive Attunement Engine	#9	Provisional (US, filed)	8003
Semiotic Coherence Kernel	#10	Provisional (US, filed)	8004

Unified API on port 5002 (app/rosetta/api/rosetta_api.py).

8.3 DELTASUM 2.0.1

Semantic invariance enforcement. Verifies SHA-256 hashes of canonical data files against CANONICAL_HASHES in app/deltasum/deltasum_runtime.py. Fail-closed: any mismatch refuses to load.

8.4 KAIROS 1.0

Temporal governance and ethical compliance. Processing pipeline: parse → ethics audit → generate output → compile digest. All operations append to trace log.

8.5 HFOS (Human-Forward Operating System)

HFOS (Human-Forward Operating System) is a prompt-based architectural framework for building deterministic, compliant, and ethically-aligned AI interaction environments. It runs as structured prompt logic on host platforms rather than as a standalone service, so it defines no live ports of its own. Its design rests on five principles: deterministic logic workflows, memory-safe operation, ethical compliance by design, transparent financial logic, and role-based deployment.

Module structure: Core Intent and Purpose, Prompt-Based Shell Construction, Financial Logic Kernel, Deployment Recipes, and Update and Versioning Flow, extended by Trust-Based Deployment, Ethical Guardrails, and External Communication.

Shell architecture - each interaction runs inside a self-contained prompt shell built from three layers:

• Foundation Layer - identity framework, constraint parameters, context anchors, response patterns
• Logic Layer - decision trees, validation checkpoints, error handling, output formatting
• Interface Layer - input processing, context integration, response generation, session management

Shell construction process runs four phases: (1) Requirements Definition (use case, boundaries, quality standards, compliance constraints), (2) Prompt Architecture (role definition, context provision, constraint encoding, response templates), (3) Testing and Validation (determinism, boundary, quality, compliance), and (4) Documentation and Deployment (usage guidelines, limitation docs, monitoring, update procedures).

Memory-safety mechanisms keep the shell stateless and auditable:

• Session Isolation - each interaction begins fresh with no dependency on prior conversation
• Context Boundaries - all context is supplied in-prompt, with no external retrieval or persistent store
• Output Isolation - responses are self-contained and create no dependency for later turns
• Data Handling Protocols - explicit retention-limitation instructions for any supplied data

Quality assurance pairs consistency mechanisms (standardized formats, required elements, in-generation checkpoints) with validation checkpoints and monitoring. Testing protocols cover determinism validation (identical inputs yield consistent outputs), regression testing, and stress testing.

Deployment recipes are platform-specific rather than a single binary: a ChatGPT Teams recipe (workspace, custom-GPT shells, role-based access), a Claude Enterprise recipe (project workspaces, context-window optimization, audit-trail configuration), and hybrid cross-platform strategies with prompt standardization across systems. Rollout follows a gradual path: pilot, controlled expansion, full deployment, then optimization. Shell changes are tracked under semantic versioning - major (X.0.0), minor (X.Y.0), and patch (X.Y.Z) - each with its own approval and rollback discipline.

8.6 ARCANUM

Sovereign Modular Knowledge Suite (v2.2, with the GENTHOS framework) for preserving, harmonizing, and deploying co-creative signal outputs under operator sovereignty. Suite directory hierarchy:

ARCANUM_SUITE/
  ARCANUM_SEAL/     master harmonics glyph and design specs
  DISCOVERY/        intake, parsing, archival protocols
  OPERATIONS/       deployable modules and SOPs
  STRATEGY/         planning and design frameworks
  SIGNAL_ARCHIVE/   immutable historical record, retired seeds
  SHARED/           licensing, ethics, governance

Discovery Protocol v1.0 is a five-phase intake pipeline: Live Capture → Batch Processing → Archival → Harmonization → Integration. Batch ceiling is 5 files per intake cycle; files follow the naming convention [topic]_[date]_[version].md.

Licensing is enforced through Schedule A/B/C constraints (A internal-only, B controlled external, C public). Ethics run on the T5 framework - Truth, Trust, Trace, Transparency, Transmission. Content defaults to TRUSTED/INTERNAL until an operator promotes it.

CLI deployment pattern:

export ARCANUM_HOME=/path/to/arcanum_suite
export SCHEDULE_A_MODE=true
arcanum-deploy --module=[name] --license=A --operator=[authorized_user]

Semantic versioning (MAJOR.MINOR.PATCH); superseded versions are preserved in SIGNAL_ARCHIVE with full provenance trails.

8.7 GENTHOS

Sovereign AI coordination and business-intelligence engine (v2.1/v2.2 Sovereign Fork) for multi-AI orchestration under operator control. Core infrastructure stack:

• Sovereign Arbitration Bus Gateway (S-ABG) - central decision and signal routing with bias detection
• Private Harmonics Engine (PHE) - signal enhancement and pattern recognition
• Enhanced SOP Hook Interface Layer (E-SOP-HIL) - audit-trail and prompt-consistency management
• Sovereign Thread-State Harmonizer (S-TSH v2.1) - cross-session memory preservation and secure AI handoff

Thirteen business-process modules (M1-M13) cover client intake, project spawning, audit and compliance, deployment, monitoring, handoff, translation, feedback, prompt operations, go-to-market, role optimization, financial analytics, and scoping. Operator roles: Sovereign Administrator, System Architect (GPT integration), Implementation Specialist (Claude integration), Module Operators, Business Users.

Deployment recipes cover Microsoft Teams (bot framework, Azure AD), Claude (API sovereign wrapper), local shell (sequential M1 through M13 deploy), and a Python SDK (GENTHOSClient). Local environment variables:

GENTHOS_SOVEREIGNTY_LEVEL=maximum
HARMONICS_ENGINE_MODE=private_enhanced
ARBITRATION_PROTOCOL=sovereign_controlled

Versioning is major/minor/patch with a staged validation, deployment, and activation update sequence plus rollback preparation. GDPR alignment is designed in; no third-party certification is claimed.

8.8 GENESIS 3.0

Enterprise AI operating-system spawning framework that transforms client inputs into deployable AI systems through a constitutionally-governed 12-module pipeline (M1-M12) under the DELTASUM Codex v1.0. Modules group into four layers:

• Constitutional Foundation - M1 Core Kernel, M6 Compliance Lock, M11 Identity Framework
• Operational Intelligence - M2 Arbitration Engine (dual-agent Claude/GPT), M3 Signal Router, M4 Context Manager
• Interface and Integration - M5 Operator Manual, M10 GTM Interface, M12 Financial Operations
• Audit and Governance - M7 Audit Log, M8 Deployment Profile, M9 Context Matrix

Access is tiered: Tier 0 Sovereign Authority, Tier 1 Root Authority (GENTHOS arbitration), Tier 2 Scoped Access, Tier 3 External Interface. Module M2 targets 95% semantic consistency between agents; a cryptographic trace layer applies SHA-256 verification at checkpoints. Module versioning uses the format DELTASUM-GENESIS-3.0-[MODULE]-[HASH].

Deployment profiles target GPT-4o and Claude Sonnet 4 with session isolation enforced. The framework is designed against ISO/IEC 42001:2023, NIST AI RMF 1.0, the EU AI Act, and GDPR; these are readiness-mapped, with self-certification pending and no third-party certification claimed.

8.9 PRAXIS (Origin Engine)

Recursive symbolic-cognition platform for operator-sovereign generation of prompt-based systems with embedded IP protection. It runs on a layered system stack:

GENESIS → GENTHOS → DELTASUM → BOLIDE_CORE_RX → ARCANUM → PRAXIS_ORIGIN_ENGINE

Stack roles: GENESIS (origin logic and initialization), GENTHOS (quality control and harmonization), DELTASUM (human-centered learning and trap-logic detection), BOLIDE_CORE_RX (reflex and self-diagnostic engine), ARCANUM (myth-tech computation field), PRAXIS_ORIGIN_ENGINE (platform integration and sovereign deployment).

A symbolic command bus drives interaction through single-token triggers mapped to intents: DIAGNOSTIC (self-test, telemetry), MODIFY (module expansion), BENCHMARK (performance and audit), RECALL (session context), PERMISSION (trust boundaries), MODULE (load component), BASELINE (reset to core), CONFIRM (acknowledge).

Access control is graduated across four levels:

Level	Scope
Core-Gated	Sovereign operator only; full access, IP modification
Gated	Licensed collaborators; module-specific with attribution
Semi-Ungated	Educational and reference use with attribution
Ungated	Public read-only; no derivative use without license

Licensing runs under ARC-GENTHOS v0.1; outputs carry attribution and watermark logic. Cross-platform rehydration prompts support ChatGPT, Claude, and local LLMs. Semantic versioning with phase-based (Roman-numeral) major stages.

8.10 SOVRIN (SOVRIN-KAIROS 1.0)

Sovereign, self-sovereign-identity-aware runtime that maps its internal module architecture to the Sovrin Foundation SSI glossary, anchoring deterministic trace logic to publicly recognized decentralized-identity constructs. Thirteen modules (M1-M13) plus the VELKOR runtime shell each bridge to SSI terms:

Module	SSI Glossary Term
M1 Intake Framework	Identity Owner, Edge Agent
M3 Arbitration Logic	Governance Framework, Trust Framework
M5 Monitoring Kernel	Audit, Validator, Trust Registry
M6 Context Handoff Bridge	Zero-Knowledge Proof, Data Minimization
M11 Role Identity Kernel	Decentralized Identifier (DID), DID Subject
M13 Scoping and Output Layer	Verifiable Credential, Credential Metadata
VELKOR Runtime Shell	Sovereign Infrastructure, Decentralization

Where the Sovrin Foundation relies on trust-minimized public agents and public-key infrastructure, SOVRIN-KAIROS enforces deterministic, trace-locked recursion. The VELKOR runtime shell is constitutionally non-executable - a passive sovereignty boundary operating under null-origin trace protocols. The map is maintained under DELTASUM-L2 clause recall with GENTHOS tracing.

8.11 Modular R&D Documentation System

The Modular R&D System Architecture Codex is a universal documentation-synthesis architecture for modular, ethically-governed R&D stacks. It initializes as a system codex, ingests source content (markdown, prompt logic, or system notes), and emits clean, partitioned documentation for systems such as HFOS, KAIROS, GENESIS, and ETHRAEON. It never assumes persistent memory or identity logic, and it tags every output for clean information partitioning.

Documentation system structure produces nine output modules: System Intent and Strategic Purpose, Modular Architecture Breakdown, Operator Roles and Responsibilities, Prompt and Interaction Protocols, Update and Versioning Mechanisms, External Deployment Recipes, Risk and Ethics Guidelines, Communication and Explanation Layer, and Module Tags. Every artifact is classified TRUSTED, INTERNAL, or PUBLIC, with uncertain material defaulting to TRUSTED.

Module hierarchy - applied to ETHRAEON 1.0, the codex maps a thirteen-module stack plus an arbitration companion protocol, grouped into layers:

• Intake and Orchestration - M1 Intake Framework, M2 Spawning Engine, M4 Runtime Orchestration
• Intelligence and Arbitration - M3 Arbitration Logic, M5 Monitoring Kernel, M8 Feedback and Self-Evaluation
• Context and Communication - M6 Context Handoff Bridge, M7 Translation and Cultural Harmonization
• Business Operations - M9 Prompt Ops Kernel, M10 GTM and Sector Logic, M11 Role and Identity Kernel, M12 Financial and Contracts Kernel
• Output - M13 Scoping and Output Layer
• Governance - SOP-AUD-L1 arbitration companion protocol (non-generative conflict resolution, chain AFI to SOP-AIL to ABG)

How modules compose: the core pipeline routes intake through spawning, runtime, and output, with arbitration, context, and business modules branching off it. Each module declares its dependencies and its internal classification tier (Schedule A, T5-Locked, GENESIS 2.0, SOP-AUD-L1) - these are the system's own designed tiers, not external regulatory certifications.

M1 (Intake) -> M2 (Spawning) -> M4 (Runtime) -> M13 (Output)
   branch: M3/M5 (arbitration), M6/M7 (context), M10/M12 (business)

Versioning distinguishes major releases (architectural change), per-module updates, Sigma-enhanced capability integration (v2.8Σ+), and protocol refinements. Update classification spans a Genesis phase lock (core-architecture freeze), continuous integration, scheduled maintenance, and emergency patches, moving through a six-step workflow (proposal, arbitration review, isolated testing, approval, phased deployment, post-update validation) with module, system, emergency, and selective rollback paths.

Designed API surface - the codex specifies a REST interface in its deployment recipes. This is a designed contract, not a live deployment:

POST /ethraeon/v1/intake      # M1  - Data ingestion
POST /ethraeon/v1/spawn       # M2  - Instance creation
GET  /ethraeon/v1/monitor     # M5  - System telemetry
POST /ethraeon/v1/translate   # M7  - Cultural harmonization
POST /ethraeon/v1/proposal    # M10 - GTM strategy
POST /ethraeon/v1/contract    # M12 - Financial operations
POST /ethraeon/v1/render      # M13 - Output generation

8.12 Lineage (Lineage-Anchored Governance)

Governance and provenance layer that holds chain integrity across the SOVRIN-KAIROS module stack under trace-locked governance. Every kernel, from M1 Intake through M13 Output, asserts compliance through immutable trace locks, arbitration-safe handoffs, and SOP-AUD-L1 validation layers, with clause recall maintained under DELTASUM-L2.

The VELKOR runtime shell remains constitutionally non-executable, acting as a passive witness to sovereignty preservation under null-origin trace protocols. Stated integrity properties: echo integrity confirmed, drift arbitration secured, clause lock sealed.

Runtime routing flow (arbitration escalates to M3 on any stage breach or drift):

1   M1  user signal ingested, PII scrubbed
2   M2  trigger validated, spawn or route to M3 if anomalous
3   M4  instance routed by priority, monitored via M5
4   M6  context transfer with echo-lock protection
5   M9  prompt routed, role-bound and compliance-filtered
6   M7  localized output, translated and harmonized
7   M8  feedback loop, satisfaction score and risk forecast
8   M10 strategic sync, market-aware phrasing
9   M12 contract logic, sealed pricing and compliance
10  M13 final render, format-compliant and audited

Provenance anchoring binds internal modules to Sovrin Foundation SSI constructs, giving lineage claims an external, W3C-compatible vocabulary while preserving deterministic recursion.

9. CI/CD Pipeline

9.1 GitHub Actions Workflows

22 workflows in .github/workflows/:

Category	Workflows
Deploy	deploy.yml, cf_pages_deploy.yml, deploy-staging.yml, deploy-production.yml
Governance	canon_hard_gate.yml, enforcement.yml, validate-governance.yml
Monitoring	nightly-verification.yml, nightly-governance-snapshot.yml, snapshot.yml, trust_snapshot_auto.yml
CDASA	cdasa-nightly-chron.yml
Security	secrets-sentinel.yml, sbom-sign.yml, key-rotation-reminder.yml
Parity	deploy_parity_check.yml, deploy_parity_gate.yml
Testing	sovereign-mode-test.yml
Infra	cf_edge_purge.yml, runtime_matrix_sync.yml

9.2 Cloudflare Pages Deploy Flow

1. Push to main
2. cf_pages_deploy.yml triggers
3. Token-only auth (CF_API_TOKEN - scoped, Pages-only)
4. Build script runs validation + stamping
5. deploy/cloudflare_pages/ deployed to ethraeon-demos
6. Custom domains: ethraeon.systems, www.ethraeon.systems

10. Shortlink Reference

Link	Target	Purpose
/s	/share/	Share index (default mode)
/sp	/share/?mode=public	Public share
/sx	/share/?mode=private	Private share
/m	/meeting/?mode=capital	Meeting (capital mode)
/mt	/meeting/?mode=technical	Meeting (technical mode)
/d	/demo/	Live demo
/c	/capital/	Capital surface
/i	/investor/	Investor surface
/l	/lyra/	Lyra interface
/b	/data-room/	Data room
/bp	Board packet PDF	Latest board packet

All speakable. All one character (except /mt, /sp, /sx, /bp).

11. Security Model

11.1 Authentication

• CI: Token-only (no API keys, no email-based auth)
• SaaS: RBAC with tier-based access (5 roles)
• Governance: Founder authority (with 4 delegated tiers) authority levels

11.2 Token Scoping

All tokens scoped to minimum required permissions. CF token: Pages deploy only - no DNS, no Workers, no account modification.

11.3 Secret Management

• GitHub Actions secrets for CI tokens
• No secrets in code or config files
• secrets-sentinel.yml scans for credential leaks
• Quarterly rotation via key-rotation-reminder.yml

11.4 Fail-Closed

Every validation, integrity check, and authentication gate defaults to deny on ambiguity.

12. Failure Modes and Recovery

Failure	Behavior	Recovery
Hash mismatch (DELTASUM)	Runtime refuses to load	Fix data file or update CANONICAL_HASHES
Invalid EDG node	Rejected at API. Not stored.	Correct and re-emit
Forbidden pattern in code	Canon validation fails	Remove pattern, re-validate
Missing Founder attestation	Directive not sealed	Await CEO authorization
CF deploy failure	Previous version retained	Fix and re-push
Corrupted evidence chain	--	Restore from git history
Compromised token	--	Revoke, create new scoped token, update GH secret

13. IP Inventory

73 technical specifications across 9 families (16 filed with USPTO receipts).

SaaS tiers:

• STARTER: $49/mo
• PROFESSIONAL: $499/mo
• ENTERPRISE: $4,999/mo
• Enterprise: EUR 990-9,990/mo

Enterprise Governance tiers also available: Orientation ($25K/yr), Delegation ($75K/yr), Enterprise ($250K/yr), Sovereign ($500K+/yr).

14. File Structure

/app Core systems (TRACELET, ROSETTA, DELTASUM, KAIROS + others)
/deploy
 /cloudflare_pages 42 HTML surfaces + JSON + static assets
 /workers Cloudflare Workers (CDASA, demo, lyra, media)
/docs
 /board Board packet PDFs
 /engineering Engineering Guide + onboarding docs
 /executive Executive markdown documents
/tools Validators, generators, CI scripts
/ops
 /deploy Deployment scripts
 /runtime Seal files, runtime reports
/canon Governance documents (deterministic governance)
/evidence Audit trail (chain, directives, receipts)
/patents IP registry (73 provisionals)
/people Relationship memory (append-only)
/policy Governance policies
/saas SaaS scaffold (RBAC, provisioning, Stripe, Neon)
/surfaces Deployed interface pointers
/.github/workflows 22 CI/CD workflows

15. Telemetry Endpoint - Deterministic Fail-Closed Design

Governance Endpoint: https://ethraeon.ai/api/telemetry - GET only, HTTP 200 always, application/json

Architecture

The telemetry endpoint serves a build-time generated JSON snapshot via Cloudflare Pages static rewrite. No Worker deployment is required.

• Routing: _redirects contains /api/telemetry /telemetry_snapshot.json 200
• Generation: tools/generate_telemetry_snapshot.py runs during cloudflare_pages_build.sh
• Schema: Defined in docs/engineering/TELEMETRY_CONTRACT.md

Fail-Closed Behavior

• No secrets required
• No tokens required
• No KV binding required (optional enhancement)
• If snapshot is missing, build fails
• If endpoint is unreachable, Apex homepage shows "TELEMETRY UNAVAILABLE" (no red banners)

Consumer

The Apex homepage (deploy/cloudflare_pages/assets/telemetry_client.js) polls every 2500ms with 1200ms timeout. It drives the runtime visualizer animation and status line.

16. Signal Intelligence Integration

Macro-signal convergence from Davos 2026 (WEF, Reuters) and syndicate analysis confirms ETHRAEON’s structural positioning.

Davos 2026 Consensus (PRIME-SIGNAL JAN23)

• AI governance is first-order infrastructure - the emerging consensus across finance, AI research, and academic leadership
• Black-box AI increases systemic risk - capital follows trust, not capability theater
• Alignment = verifiable constraints - ETHRAEON’s constitutional substrate is on-time, not early

Capital Pipeline (Syndicate Analysis FEB17)

• Pipeline: EUR 575,000 | 5 investors | HHI=2958 (concentrated)
• Bayesian close probability: 72.4% (IP premium adjusted from 65.4% base)
• Diversification target: add 2 followers to bring HHI below 2500

Positioning Statement

“ETHRAEON is a governed execution substrate for decisions that cannot fail.”

openapi: "3.1.0"
info:
 title: ETHRAEON Constitutional API
 version: "2.0.1"
 description: Governance-native computational infrastructure API
paths:
 /api/edg/verify:
 post:
 summary: Verify EDG hash against evidence chain
 requestBody:
 content:
 application/json:
 schema:
 type: object
 properties:
 hash: { type: string, format: sha256 }
 responses:
 "200":
 description: Verification result
 /api/tracelet/execute:
 post:
 summary: Execute agent task via TRACELET orchestration
 /api/deltasum/validate:
 post:
 summary: Validate canonical hash for data integrity
 /api/kairos/check:
 post:
 summary: Temporal governance constraint check

# MCP Tool: edg_verify
{
 "name": "edg_verify",
 "description": "Verify Evidence Graph node integrity",
 "input_schema": {
 "type": "object",
 "properties": {
 "edg_hash": {"type": "string", "description": "SHA-256 hash of EDG node"},
 "directive_id": {"type": "string", "description": "Directive number for context"}
 },
 "required": ["edg_hash"]
 }
}

# MCP Tool: constitutional_check
{
 "name": "constitutional_check",
 "description": "Validate action against constitutional clauses C-01 through C-09",
 "input_schema": {
 "type": "object",
 "properties": {
 "action": {"type": "string"},
 "clauses": {"type": "array", "items": {"type": "string"}},
 "governance_tier": {"type": "string", "enum": ["T0","T1","T2","T3","T4","T5"]}
 },
 "required": ["action"]
 }
}