Delivery Model

SPEC_DELIVERY_MODEL.md · 2026-04-20

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


OUTPUTS


INVARIANTS

  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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

  1. 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.
  1. API key revocation: Client API key is revoked when subscription lapses. Σ.✓ iff test call to AETHER API with a lapsed key returns 401 Unauthorized.
  1. 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.
  1. 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.
  1. 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.
  1. 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

  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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


DEPENDENTS


GAPS

  1. [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.
  1. [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.
  1. [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.
  1. [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.
  1. [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:

Violation example (never do this):


REFERENCES

Φ 0.042. The delivery model IS the protection model.


Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042