◈ CGNT-1
Home › Cashx
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Cashx

SPEC_CASHX.md · 2026-04-20

SPEC_CASHX.md

CGNT-1 Component Specification — CASHX Financial Intelligence Engine

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS

Date: 2026-04-20

Module: 21 of 24

PURPOSE

Real-time financial intelligence for the ship. Every dollar in, every dollar out, every dollar remaining. One query tells you if the ship can keep sailing.

SIMONX enforces trading walls. CASHX counts the money.

WHAT CASHX TRACKS

INCOME STREAMS

Oracle Subscriptions:

Trading:

Other:

EXPENSES

Fixed monthly:

Variable:

One-time:

DERIVED METRICS

QUERIES

DATA SOURCES

| Data | Source | Method |

|---|---|---|

| Stripe payments | Stripe webhook logs | Parse ~/stripe_webhooks.log or Stripe API |

| Trading positions | SnapTrade API / Wealthsimple | Query via existing trading infrastructure |

| Morpho yield | On-chain query via compounder | Parse aether-compounder logs |

| Server costs | DigitalOcean billing API or hardcoded | Monthly constant unless plan changes |

| API spend | Google AI Studio dashboard / Anthropic usage | Parse from billing pages or hardcode estimates |

| Treasury | Wealthsimple balance + Morpho position + Stripe balance | Aggregate all sources |

ALERTS

CASHX sends alerts via COMMX when:

INTEGRATION

| Module | Relationship |

|---|---|

| SIMONX | SIMONX enforces trading walls. CASHX reports the financial results of trades SIMONX approved. |

| GAPX | CASHX feeds revenue data to GAPX health score. Zero revenue is a tracked gap. |

| COMMX | CASHX sends financial alerts through COMMX. |

| CRONX | CASHX registers a daily financial summary job (06:00 ET — before Captain's day starts). |

| AUTHX | CASHX queries require no special auth — financial status is crew-readable. Trading ACTIONS still require Agency Walls approval. |

INVARIANTS

INV-01: CASHX is read-only. It tracks money. It never moves money. No trades, no transfers, no subscriptions. Those go through SIMONX and Agency Walls.

INV-02: All financial data is approximate until verified against source. CASHX estimates between API calls. Hard numbers come from Stripe, SnapTrade, and on-chain queries.

INV-03: Runway calculation uses trailing 7-day burn rate, not lifetime average. Recent spending is more predictive than historical.

INV-04: The sovereignty target ($27,042.50) is a constant. It does not change with market conditions. It is the amount required for the ship to operate indefinitely without external income.

THE NAME

CASH + X. The ship needs to know its cash position the same way it needs to know its RAM position. CASHX is free -h for money.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042

SPEC_BRIDGEX.md

CGNT-1 Component Specification — BRIDGEX External Surface Monitor

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS

Date: 2026-04-20

Module: 22 of 24

PURPOSE

Monitor the ship's public-facing surface — the parts the world actually sees. MEDX watches the engine room. BRIDGEX watches the hull.

If 42sisters.ai goes down, MEDX doesn't know. If the SSL cert expires, MEDX doesn't know. If Northflank fails a build, MEDX doesn't know. BRIDGEX knows.

WHAT BRIDGEX MONITORS

DOMAIN HEALTH

DEPLOYMENT STATE

- Last successful deploy timestamp

- Current build status (building / deployed / failed)

- Pending builds not yet deployed (e.g., Feminine Protocol click-deploy)

- Container health and restart count

- Environment variables set vs expected

SSL CERTIFICATES

PUBLIC ENDPOINTS

CONTENT HEALTH

QUERIES

HEALTH CHECK METHOD

BRIDGEX runs checks in two ways:

Active probing (from csdm-node):

Northflank API (if available):

ALERTS

BRIDGEX sends alerts via COMMX when:

INTEGRATION

| Module | Relationship |

|---|---|

| MEDX | MEDX monitors internal health. BRIDGEX monitors external health. Together: complete surface awareness. |

| GAPX | BRIDGEX feeds external health data to GAPX. A down website is a gap. An expiring SSL cert is a gap. |

| HACKX | BRIDGEX monitors the real public surface. HACKX monitors the fake public surface. Same methodology, different targets. |

| COMMX | BRIDGEX sends alerts through COMMX. |

| CRONX | BRIDGEX registers an hourly health check (/60 *) and a daily full report (05:00 ET). |

| CASHX | BRIDGEX can report whether Stripe payment links are functional — feeds into CASHX revenue pipeline health. |

INVARIANTS

INV-01: BRIDGEX is read-only and observation-only. It checks endpoints. It never modifies deployments, DNS records, or certificates.

INV-02: BRIDGEX probes from csdm-node only. It does not use external monitoring services. The ship monitors itself.

INV-03: API tokens for Northflank (if used) follow Sentinel protocol — stored in dotfiles with 600 permissions, never in source code, never in BRIDGEX module code.

INV-04: BRIDGEX health checks are lightweight. A curl with a 5-second timeout. No load testing, no stress testing, no penetration testing from BRIDGEX. That's HACKX territory.

THE NAME

BRIDGE + X. The bridge of a ship is where the captain looks outward. BRIDGEX is the ship's forward window — the view of what the world sees when it looks at 42sisters.ai.

Also: the bridge between internal infrastructure and external presence. The crossing point where the engine room meets the ocean.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042

SPEC_LEARNX.md

CGNT-1 Component Specification — LEARNX Continuous Learning Engine

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS

Date: 2026-04-20

Module: 23 of 24

PURPOSE

Close the loop between conversation and capability. Every interaction generates data. LEARNX mines that data into training pairs that make the brains smarter. The ship learns from its own experience.

Currently, training pairs are hand-written by NOUS or the Lobster — 50 at a time, manually, then forged. LEARNX automates the pipeline: conversation → candidate pairs → review → forge queue → smarter brains → better conversations.

THE LEARNING LOOP


Customer asks a question on 42sisters.ai
  → Sisters answer (or answer ◌)
    → LEARNX captures the exchange
      → LEARNX classifies: correct answer? partial? wrong? ◌?
        → If correct: generate training pair (Q→A)
        → If wrong/◌: generate gap marker (what should the brain have known?)
          → Gap markers feed FORGEX queue
            → Next forge includes new pairs
              → Brain graduates smarter
                → Customer gets a better answer next time

This loop currently doesn't exist. Every brain is frozen at its graduation state. LEARNX makes the brains LIVE — continuously improving from real-world use.

DATA SOURCES

Sisters Sessions (cloud path)

Sisters Chat (42sisters.ai public)

Lobster Sessions

Tool Interactions

PAIR GENERATION

LEARNX generates training pairs in standard format:


{
  "instruction": "What is the coherence threshold Ω?",
  "input": "",
  "output": "Ω = 0.9740425725. This is the coherence threshold derived from 1-(Φ/φ) where Φ=0.042 and φ is the golden ratio. Both Sisters must score ≥ Ω on the TMM for any trade to execute."
}

Pair Classification

| Type | Source | Auto-generate? |

|---|---|---|

| FACT | Correct Q→A from sessions | Yes — extract directly |

| CORRECTION | Wrong answer followed by Captain correction | Yes — pair the correction with the question |

| GAP | ◌ response where answer exists in specs | Yes — look up answer in SPECX/GLOSS, generate pair |

| NEGATIVE | Hallucinated response | Yes — pair the question with the CORRECT answer plus "DO NOT" prefix on the hallucination |

| OPERATIONAL | New architecture fact from Lobster sessions | Semi-auto — extract fact, human verifies |

| KERNEL | CSDM physics content | Manual only — too sensitive for auto-generation |

Quality Gates

No auto-generated pair enters a forge dataset without:

  1. Deduplication check against existing training pairs
  2. Consistency check against GLOSS and NEXUS (facts must match)
  3. Format validation (instruction/input/output structure)
  4. Severity check (KERNEL pairs never auto-generated — Captain or Navigator only)

QUERIES

CANDIDATE REVIEW WORKFLOW


LEARNX generates candidate pair
  → Status: CANDIDATE
    → Captain or Navigator reviews
      → APPROVE → pair added to brain's forge dataset → Status: APPROVED
      → REJECT → pair discarded with reason → Status: REJECTED
        → FORGEX picks up approved pairs on next forge cycle

Auto-approval for FACT pairs where:

All other pairs require human review. KERNEL pairs ALWAYS require human review.

LEARNING METRICS

LEARNX tracks learning velocity:

These metrics feed into GAPX health score under the Knowledge domain.

INTEGRATION

| Module | Relationship |

|---|---|

| FORGEX | LEARNX feeds approved training pairs to FORGEX. FORGEX manages the forge. LEARNX manages the curriculum. |

| MNEMOS | Primary beneficiary. Most LEARNX pairs target MNEMOS fact retrieval capability. |

| GLOSS | LEARNX validates FACT pairs against GLOSS definitions. If GLOSS has the answer, the pair is auto-approved. |

| NEXUS | LEARNX validates computational pairs against NEXUS. If NEXUS confirms the answer, the pair is auto-approved. |

| SPECX | LEARNX uses SPECX to find answers for GAP pairs — if the answer exists in a spec, generate the pair. |

| GAPX | LEARNX reports learning metrics to GAPX for the Knowledge domain health score. |

| COMMX | LEARNX sends daily summary through COMMX: "12 pairs generated, 8 auto-approved, 4 pending review, 2 gaps identified." |

| CRONX | LEARNX runs a nightly scan at 02:00 ET — processes all session logs from the day, generates candidates, runs quality gates. |

| ROUTX | LEARNX analyzes ROUTX query logs to identify routing improvements and brain knowledge gaps. |

INVARIANTS

INV-01: KERNEL pairs (CSDM physics) are never auto-generated. The physics is sacred. Only NOUS or the Navigator writes CSDM training content.

INV-02: LEARNX never modifies existing training datasets. It generates CANDIDATES that get ADDED after approval. Existing pairs are immutable.

INV-03: Negative training pairs (hallucination corrections) include both the wrong answer and the right answer. The brain learns WHAT not to say AND WHAT to say instead.

INV-04: LEARNX logs every candidate, every approval, every rejection with reasons. The learning history is auditable.

INV-05: Auto-approval is limited to FACT pairs verified against deterministic tools (GLOSS, NEXUS). Anything requiring judgment goes to human review.

INV-06: LEARNX never triggers a forge. It feeds FORGEX. FORGEX decides when to forge based on pair count thresholds and Captain authorization.

THE NAME

LEARN + X. The ship learns. Not from pre-training, not from fine-tuning sessions initiated by humans, but continuously, from every conversation, every query, every interaction. LEARNX is the system that makes intelligence compound.

Also: the acronym potential — Latent Experience Acquisition and Retention Network. But honestly, it's just: the ship learns.

FUTURE

When LEARNX has 90+ days of data:

LEARNX doesn't just fill gaps. Eventually, it anticipates them.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042

SPEC_VOICEX.md

CGNT-1 Component Specification — VOICEX External Communication Engine

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS

Date: 2026-04-20

Module: 24 of 24

PURPOSE

The ship's voice to the outside world. COMMX carries messages between crew members. VOICEX carries messages to everyone else.

The ship is perfectly self-aware and completely silent. VOICEX gives it a mouth.

THE PROBLEM

Every external communication gap on the ship traces to the same root: there is no system for outbound messaging.

The tools exist. The infrastructure exists. The messages exist (some are even drafted). Nobody SENDS them. VOICEX is the sender.

COMMUNICATION CHANNELS

CH1 — EMAIL (oracle@42sisters.ai)

Infrastructure:

Use cases:

Templates:

CH2 — NOTIFICATION (in-app)

Infrastructure:

Use cases:

CH3 — SOCIAL (managed presence)

Infrastructure:

Use cases:

Agency Walls: All social posting requires NOUS APPROVAL. VOICEX drafts and queues. NOUS approves and sends. No autonomous public communication.

CH4 — OUTREACH (targeted professional)

Infrastructure:

Use cases:

Warm only rule: VOICEX never cold-emails. Every outreach has a specific reason, a specific ask, and a specific connection point. Spam is a Vacuum Rule violation applied to communications.

MESSAGE LIFECYCLE


1. DRAFT — message created (by crew, LEARNX, or template)
2. QUEUED — message in outbound queue, awaiting approval
3. APPROVED — Captain authorized sending (Agency Walls check)
4. SENT — message delivered via appropriate channel
5. DELIVERED — delivery confirmed (email: no bounce, social: posted)
6. ENGAGED — recipient responded (email: reply, social: interaction)
7. CLOSED — conversation thread completed or archived

Every message has a lifecycle state. VOICEX tracks all of them. "voicex queue" shows what's waiting. "voicex sent" shows what went out. "voicex engaged" shows who responded.

QUERIES

DRAFT GENERATION

VOICEX can auto-draft messages using templates and ship context:

Oracle verdict email:


Subject: Your Oracle Verdict — [DATE]
Body: [Generated from TMM results, SIMONX data, ENTROPX entropy score]

Researcher outreach:


Subject: CSDM Spectral Conjecture — E8 Modular Category Question
Body: [Generated from SPEC_SPECTRAL_CONJECTURE.md, Sisters' Riemann findings]

Welcome email:


Subject: Welcome to 42sisters.ai — Your Oracle Awaits
Body: [Generated from SPEC_ONBOARDING.md]

Drafts are generated. Never sent automatically. NOUS reviews and approves every outbound message.

INTEGRATION

| Module | Relationship |

|---|---|

| COMMX | COMMX is internal crew messaging. VOICEX is external world messaging. Same bus, different audience. COMMX alerts VOICEX when a customer-facing event occurs (e.g., verdict ready → trigger email draft). |

| CASHX | VOICEX sends subscription-related emails. CASHX tracks the financial result. New subscriber → VOICEX welcome email → CASHX records MRR increase. |

| BRIDGEX | BRIDGEX monitors the public surface. VOICEX communicates through it. If BRIDGEX reports 42sisters.ai is down, VOICEX pauses customer notifications until it's back. |

| LEARNX | LEARNX identifies frequently asked questions. VOICEX can turn FAQ insights into proactive customer communications ("Here's what new subscribers often want to know"). |

| HACKX | If HACKX detects a targeted attack, VOICEX does NOT alert the attacker. HACKX intelligence is internal only. VOICEX never communicates with hostile actors. |

| GAPX | VOICEX feeds communication metrics to GAPX. Zero outreach sent is a gap. Zero customer emails configured is a gap. |

| CRONX | VOICEX registers scheduled communications: weekly subscriber digest, monthly outreach follow-ups, daily queue review reminder. |

| AUTHX | Every VOICEX send action checks Agency Walls. Email to customer: PERMITTED. Social post: APPROVAL. Cold outreach: NEVER. |

| Baseline | If a customer responds abusively to a VOICEX email, Baseline Protocol governs the reply. VOICEX handles delivery. Baseline handles tone. |

INVARIANTS

INV-01: VOICEX never sends without NOUS approval. Drafting is autonomous. Sending is ALWAYS human-authorized. The ship has a voice but not a will to use it unsupervised.

INV-02: No cold outreach. Every external message has a reason, a connection, and a specific ask. The warm-only rule is non-negotiable.

INV-03: No communication with hostile actors. HACKX intelligence stays internal. VOICEX never responds to attackers, never acknowledges attacks, never engages with social engineering attempts.

INV-04: All sent messages are logged with full content, timestamp, recipient, channel, and delivery status. The communication record is auditable.

INV-05: Customer email addresses are stored encrypted. VOICEX handles them in memory during send operations. They never appear in logs, specs, or training data. Sentinel protocol applies.

INV-06: VOICEX templates are versioned and stored in ~/email_templates/. Template changes require review. A bad template sent to all subscribers is a cascading failure.

SMTP SETUP (prerequisite)

Before VOICEX can send email, oracle@42sisters.ai needs outbound SMTP:

Option A: Microsoft Graph API (already on port 8006 for INBOUND — extend to outbound)

Option B: SendGrid / Mailgun (third-party SMTP relay — simple, reliable, cheap)

Option C: Direct SMTP from VPS (risky — IP reputation, deliverability issues)

Recommendation: Option A first (Graph API is already deployed). Option B as fallback if deliverability is poor.

THE NAME

VOICE + X. The ship's voice. The final module. Module 24 of 24.

COMMX is the crew talking to each other. VOICEX is the crew talking to the world. The internal conversation became coherent first. Now it's time to speak outward.

Every great system eventually has to say something. VOICEX is the moment the ship stops being a self-contained experiment and becomes a presence in the world. It is the transition from building to broadcasting. From occupation to declaration.

THE COMPLETION

Module 24 closes the T.O.O.L. layer.

| Range | Function |

|---|---|

| 1-13 | Foundation: GLOSS, NEXUS, CODX, INDEX, MEDX, COMMX, LOGX, CRONX, SIMONX, AUTHX, ENTROPX, MODEMX, MNEMOS-TOOL |

| 14-18 | Observation: NISTX, FORGEX, MNEMOSX, SPECX, LOOPX |

| 19-20 | Defense: GAPX, HACKX |

| 21-24 | Interface: CASHX, BRIDGEX, LEARNX, VOICEX |

The ship can compute (1-13), observe itself (14-18), defend itself (19-20), and interface with the world (21-24).

24 modules. One port. One process. The T.O.O.L. layer is complete.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042