Delivery Model
SPEC_DELIVERY_MODEL — Delivery Model (SaaS Only)
Version: 1.0 | Status: AUTHORIZED | Authority: α.13 | Date: 2026-04-16
PURPOSE
The CGNT-1 Delivery Model is the structural IP protection doctrine for all products and services offered by 42 Sisters AI. It establishes that nothing leaves the ship — clients access products via URL and API; they never possess model files, source code, specifications, training data, or binaries. SaaS is not just a business model; it is the architecture of the moat. The delivery model IS the protection model. This spec governs every build decision, product decision, and client conversation. It is the physical instantiation of S.O.S. v2 Pillar 2.
INPUTS
- A client engagement (new or existing)
- A product or service to be delivered (GLOSS, AETHER, Custom AI Build, Oracle Toll, THE RING, etc.)
- A payment arrangement (Stripe, subscription tier, or enterprise contract)
- A client-specific subdomain request (client-name.42sisters.ai)
OUTPUTS
- Client receives: A subdomain URL (
client-name.42sisters.ai), an API key for programmatic access, a usage/verdicts/telemetry dashboard, and documentation on how to communicate with AETHER - Client never receives: Model files, source code, LX specification, training data, downloadable binaries, USB drives, DVDs, or any physical media containing IP
- Payment confirmation linked to URL activation
- URL deactivation event on payment lapse
INVARIANTS
- Nothing leaves the ship. No model file, binary, source code, LX spec, or training dataset is ever transmitted to a client under any circumstances — including under NDA. The single exception is the on-premise enterprise device (see Invariant 5), which ships under strict kill-switch enforcement.
- Client accesses the product; client never possesses the product. The distinction is architectural, not contractual. Contractual protections (NDA, ToS) are supplementary — they are not the primary defense. The primary defense is that the asset never leaves the server.
- Payment cessation triggers access termination. When a client's payment lapses: URL goes dark, API key revokes, access terminates. The agent, training data, and personality stay on the ship. The client has no local copy to continue using.
- Custom AI Builds run on CGNT-1 servers. A custom agent configured to a client's specifications runs on 42 Sisters AI infrastructure. The client accesses it via a branded URL. The agent is never compiled, packaged, or shipped as a standalone artifact.
- On-premise exception requires kill-switch before shipment. The sole exception to "nothing leaves the ship" is the future locked-device enterprise tier. This requires: (a) signed container on locked hardware, (b) phone-home activation and update channel, (c) payment stop → device bricks, (d) client never sees code or model files on the device. This tier does not exist yet — it is authorized in design only and requires NOUS authorization before any device ships.
- Any build decision that results in a client possessing IP violates this spec. A client "possessing" IP means: they have a file they can copy, run offline, or redistribute without our infrastructure. Even under NDA, possession transfers risk. This invariant is checked at design time, not at delivery time.
- S.O.S. v2 alignment is required. Every product offering must comply with all three S.O.S. v2 pillars: (1) show results, never show method; (2) nothing leaves the ship; (3) clients feed the evolution. A product that violates any pillar requires α.13 review before launch.
VERIFICATION CRITERIA
- URL activation gate: Client subdomain is live if and only if payment is active in Stripe. Σ.✓ iff manual test: cancel subscription → URL returns 404 or maintenance page within one billing cycle.
- API key revocation: Client API key is revoked when subscription lapses. Σ.✓ iff test call to AETHER API with a lapsed key returns 401 Unauthorized.
- No file delivery path in codebase: No script, endpoint, or workflow in the CGNT-1 codebase has a function that writes or transmits a model file, source tree, or LX spec to an external address. Σ.✓ iff
grep -r "model.bin\|model.gguf\|send.spec\|transmit.source" /home/nous/returns no delivery-targeted results.
- Custom AI Build isolation: A client's custom agent is deployed as a server-side process only. No packaging step (Docker export, binary bundle, zip-with-code) produces a client-deliverable artifact. Σ.✓ iff build pipeline audit shows no export-to-client step.
- On-premise device gate (future): Before any device ships, verify: (a) phone-home endpoint is live and tested, (b) payment-stop bricks device in test environment, (c) NOUS authorization recorded in SESSIONS.md. Σ.✓ iff all three verified before first shipment.
- Client dashboard scope audit: Client dashboard exposes only: usage metrics, verdict telemetry, account status. It does not expose: model architecture, prompt structure, training data counts, LX symbol inventory, or crew architecture. Σ.✓ iff dashboard code review confirms no protected fields are accessible to client tier.
FAILURE MODES
- Accidental file delivery (Σ.☠ — CRITICAL): A build script or engineer includes a model file or source code in a client onboarding package. Cause: automation error, misconfigured CI/CD. Result: IP leaves the ship — irreversible. Mitigation: no build pipeline has a client-delivery step; file delivery paths are blocked at infrastructure level.
- NDA false security (Σ.⊖): A decision is made to send IP to a client "because there's an NDA." Cause: conflation of contractual protection with structural protection. Result: IP possessed by client; NDA is not enforcement, it is lawsuit-after-the-fact. Mitigation: NDA is supplementary; invariant 2 is structural and overrides NDA reasoning.
- Payment lapse without URL deactivation (Σ.⊖): Client subscription lapses but URL remains live due to Stripe webhook failure or deployment gap. Cause: webhook reliability failure. Symptom: lapsed client continues to access product. Mitigation: webhook monitoring; fallback polling check on subscription status.
- On-premise device without kill-switch (Σ.☠ — CRITICAL): A device ships before phone-home and payment-stop brick are implemented and tested. Cause: schedule pressure, incomplete implementation. Result: client possesses physical device with code/model; kill-switch unavailable. Mitigation: NOUS authorization required; kill-switch test is a hard gate before shipment.
- Subdomain enumeration (Σ.⊖): A client discovers another client's subdomain URL pattern and probes it. Cause: predictable naming scheme. Result: unauthorized access attempt (not data leak — model still on server). Mitigation: authentication required at all subdomains; API key validated before any response returned.
- Custom build scope creep (Σ.⊖): Client requests "their version" of the agent as a deliverable binary or Docker image. Cause: unclear contract scope; client misunderstanding of delivery model. Result: pressure to violate Invariant 4. Mitigation: contract language explicitly excludes artifact delivery; sales and onboarding process enforces this upfront.
- Partial source leak via dashboard (Σ.⊖): Dashboard inadvertently exposes internal prompt structure, model architecture hints, or LX symbol inventory through API responses or telemetry fields. Cause: over-permissive API response schema. Mitigation: dashboard API audit per VC-6; client tier = results only, never method.
DEPENDENCIES
- Stripe — payment processing and subscription state management
- DNS provider — subdomain activation/deactivation on payment state
- CGNT-1 server infrastructure — all agents, models, and code run here; never on client hardware
- S.O.S. v2 (
~/memories/SOS_v2.md) — three-pillar doctrine this spec instantiates - AETHER frontend — the single voice clients interact with; crew hidden by default
- Authentication layer (API key management) — enforces access control at every endpoint
DEPENDENTS
- All CGNT-1 products — GLOSS, AETHER, Custom AI Builds, Oracle Toll, THE RING, NARCIS
- Sales and onboarding process — must communicate this model to clients upfront
- Future on-premise tier — governed by Invariant 5; cannot ship without this spec satisfied
- SPEC_CIVILIZATION.md — Delivery Model is an economic layer of the civilization (Pillar 7)
GAPS
- [GAP — needs design] Stripe webhook reliability spec: No formal spec for handling Stripe webhook failures (missed payment event, retry logic, reconciliation). Payment lapse without URL deactivation (Failure Mode 3) requires a reliability protocol.
- [GAP — needs design] On-premise device kill-switch implementation: Phone-home endpoint, heartbeat protocol, and brick mechanism are authorized in design but not built. Full spec required before any on-premise device is manufactured.
- [GAP — needs design] Subdomain naming convention: No canonical spec for how client subdomains are named. Predictable patterns create enumeration risk. A naming scheme that balances usability and obscurity is needed.
- [GAP — needs design] Contract language template: No standard contract or terms of service template that explicitly excludes artifact delivery and establishes SaaS-only access. Legal document needed before Custom AI Builds are sold.
- [GAP — needs design] Dashboard API schema audit process: No formal process for auditing dashboard API responses to confirm no protected fields are exposed to client tier. Needs a repeatable audit checklist.
EXAMPLES
Correct client delivery:
- Client "Acme Corp" → receives
acme.42sisters.ai, API keysk-acme-xxxx, dashboard link - Acme accesses AETHER, receives verdicts, sees usage telemetry
- Acme's subscription lapses →
acme.42sisters.aireturns 402/maintenance → API key returns 401 - Acme's custom agent and training data remain on CGNT-1 servers
Violation example (never do this):
- Client requests "a copy of the model to run on-premises"
- Engineer sends
mnemos-v6.ggufvia email "just this once under NDA" - → INVARIANT 2 violated. IP has left the ship. NDA is not structural protection.
- Correct response: "Our delivery model is SaaS only. On-premise tier is in design. When available, it ships as a locked device with kill-switch — no model files are ever transmitted."
REFERENCES
/home/nous/memories/DELIVERY_MODEL.md— source doc (α.13 + ⊹, 2026-04-12)/home/nous/memories/SOS_v2.md— S.O.S. v2 three-pillar doctrine/home/nous/memories/AETHER_FRONTEND.md— single-voice AETHER frontend spec/home/nous/memories/CUSTOM_AI_BUILDS.md— Custom AI Builds product line/home/nous/CLAUDE.md— governance; NOUS authorization requirements
Φ 0.042. The delivery model IS the protection model.
Jeremy Zlabis
Chronogeometer · Visionary · Disruptor · Chief
42 Sisters AI · East York, Toronto
🍁 Φ 0.042