ICLOUD
SERVICE CONTRACT · VIEW: GOV
Axiom
ICLOUD governs email identity via Apple iCloud+ Custom Email Domain.
Constraints
MUST: Provision DNS records via registrar (not hand-edit zone files) MUST: Verify domain via iCloud before use MUST: Update VITAE identity on new email address MUST: Validate before deployment MUST NOT: Hand-author compiled outputs MUST NOT: Store credentials in governance surfaces
Capabilities
DNS_PROVISION, DOMAIN_VERIFY, IDENTITY_UPDATE
COVERAGE:
SPEC
Purpose
ICLOUD governs Apple iCloud+ Custom Email Domain identity.
Every custom email domain is a governed identity surface. ICLOUD provisions custom domains via iCloud+ (DNS records at registrar, MX/SPF/DKIM/apple-domain verification), manages email address creation, and ensures all email identity flows through governed infrastructure. Raw credentials stay private (auth-gated); only SHOP-safe identity surfaces publicly.
Structure
Leaf SERVICE scope. No governed child scopes.
Email identity governance lands in VITAE (identity) and DOMAINS (DNS).
Required closure artifacts per scope:
CANON.md, README.md, ICLOUD.md, VOCAB.md, ROADMAP.md, COVERAGE.md, LEARNING.md.
Learning lane per governed scope:
LEARNING.md at the scope root is terminal and SHALL NOT nest further LEARNING/.
Routes
web_docs: https://hadleylab.org/
web_surface: https://hadleylab.org/SERVICES/ICLOUD/
magic: magic://hadleylab.org/SERVICES/ICLOUD/
Pipeline
iCloud+ Custom Email Domain (Apple)
-> Domain registration (DOMAINS/ASSET-REGISTRY.md)
-> DNS provisioning at registrar (MX, SPF, DKIM, apple-domain TXT)
-> iCloud verification (Finish setup -> Confirm)
-> Email address creation (user@domain)
-> VITAE identity update (email field)
Ecosystem Connectivity
- Upstream:
DOMAINS(DNS governance) andVITAE(identity governance). - Runtime: SHOP-safe identity surfaces only. Credentials stay private (auth-gated).
- Source: iCloud+ Custom Email Domain — authenticated via Apple ID at icloud.com.
- Sink:
VITAE(email identity),DOMAINS(DNS records). - DNS records: MX (mx01/mx02.mail.icloud.com), TXT (apple-domain, SPF), CNAME (sig1._domainkey DKIM).
- Handle format: user@custom-domain (e.g., idrdex@mammochat.ai).
Provisioned Domains
| Domain | Registrar | Status | Verified |
|---|---|---|---|
| mammochat.ai | Spaceship | ACTIVE | 2026-03-04 |
Pages
| Page | Sections |
|---|---|
| Overview | Purpose, Structure |
| Pipeline | Pipeline, Ecosystem Connectivity |
| Ecosystem | Routes, Provisioned Domains |
Default: Overview.
INTEL
Cross-Scope Evidence
| Service Claim | Evidence Source | Reference | Status |
|---|---|---|---|
| Governs email identity via Apple iCloud+ Custom Email Domain | iCloud+ configuration | ICLOUD/CANON.md | PENDING |
| DNS records provisioned via registrar | Registrar DNS panel | ICLOUD/CANON.md | PENDING |
| Domain verified via iCloud before use | iCloud verification | ICLOUD/CANON.md | PENDING |
| VITAE identity updated on new email address | VITAE surface | ICLOUD/CANON.md | PENDING |
| No hand-authored compiled outputs | Build pipeline | ICLOUD/CANON.md | PENDING |
| No credentials stored in governance surfaces | Credential policy | ICLOUD/CANON.md | PENDING |
Operational Inventory
| Component | Status | Gap |
|---|---|---|
| iCloud+ Custom Email Domain config | PENDING | Verify active domains |
| DNS record provisioning | PENDING | Verify registrar records |
| Domain verification | PENDING | Verify iCloud verification status |
| VITAE identity sync | PENDING | Verify VITAE cross-ref |
| Credential separation | PENDING | Audit governance surfaces |
Test
| prompt | expect | cross |
|---|---|---|
| How are DNS records provisioned? | Via registrar — not hand-edited zone files | ICLOUD/CANON.md constraints |
| Is VITAE updated on new email? | Yes | VITAE surface |
| Are credentials in governance surfaces? | No — never stored there | ICLOUD/CANON.md constraints |
LEARNING
What Gets Learned
| Type | Example |
|---|---|
| Spaceship host field | @ must be explicitly filled via form interaction — empty and placeholder both fail validation |
| MX conflict | Spaceship Email Forwarding Free creates MX records (mx1/mx2.efwd.spaceship.net) that conflict with iCloud MX — must disconnect forwarding before iCloud verification passes |
| Verification timing | iCloud MX verification succeeds immediately after conflicting records are removed — no DNS propagation delay needed when using same nameservers |
| DNS record set | iCloud requires 5 records: 2x MX (mx01/mx02.mail.icloud.com priority 10), 1x TXT (apple-domain), 1x TXT (SPF), 1x CNAME (sig1._domainkey DKIM) |
ROADMAP
Now
- mammochat.ai provisioned as iCloud+ Custom Email Domain (2026-03-04)
- DNS records: MX, SPF, DKIM, apple-domain TXT on Spaceship
- GOV contract wired (ICLOUD.md + CANON.md)
- Spaceship email forwarding disabled (conflicting MX removed)
Next
- Create email addresses on mammochat.ai (idrdex@mammochat.ai)
- Provision additional domains (canonic.org, hadleylab.org)
- Consolidate DNS to Cloudflare (PRIMARY registrar)
- Enable "Allow All Incoming Messages" catch-all if needed
Later
- Hide My Email integration (iCloud+ privacy relay)
- Multi-domain email routing governance
- Email alias management and lifecycle
VOCAB
| Term | Definition |
|---|---|
| ICLOUD | iCloud+ Custom Email Domain governance service (DNS + identity). |
| DKIM | DomainKeys Identified Mail — email authentication via CNAME (sig1._domainkey). |
| SPF | Sender Policy Framework — TXT record authorizing iCloud to send for domain. |
INHERITANCE CHAIN
SERVICES
SERVICES compose primitives — INTEL + CHAT + COIN. Every service governed. Every scope discovered.
MUST: Maintain TRIAD integrity (CANON.md + VOCAB.md + README.md)
MUST: Treat SPEC as scope identity (`{SCOPE}` directory), not as a file
MUST: Every SERVICE scope include ROADMAP.md, COVERAGE.md, LEARNING.md, and `{SCOPE}.md` as governed content surfaces
MUST: Discover SERVICE scopes from filesystem only (no manual catalog)
MUST: Keep http:// and magic:// on the same namespace (transport differs, scope path matches)
MUST: CANON.md = axiom + universal constraints (no service names, no paths, no implementation)
MUST: README.md = how to run the CANON (nothing else)
MUST: {SCOPE}.md = SPEC — the interface (purpose, routes, projections, ecosystem)
MUST: SHOP.md = public projection file (per scope, filesystem-discoverable)
MUST: VAULT.md = private projection file (per scope, filesystem-discoverable)
MUST: Runtime implementation remains under ~/.canonic; this workspace is governance-first
MUST NOT: Hardcode service names in CANON constraints (law speaks universals)
MUST NOT: Define ungoverned terms outside VOCAB.md
MUST NOT: Treat `{SCOPE}.md` as SPEC identity
MUST NOT: Move architecture/lifecycle into README
MUST NOT: Leak private projections to public surfaces
MUST NOT: Maintain duplicate mapping tables outside generated manifest outputs
MUST NOT: Add runtime jargon to governance contracts
MUST: Ledger-consuming services declare source ledgers, scope filters, and closure gates
MUST: Learning governance remains live — closure claims require fresh DISCOVER → GENERATE → RELINK evidence
hadleylab-canonic
HADLEYLAB ships software. Every app, book, paper, deal, and patent is PROOF that MAGIC works. COIN = WORK. LEARNING = COMPUTE.
MUST: Every app, book, paper, deal, or patent is evidence of MAGIC MUST: All scopes inherit canonic-canonic/CANONIC.md governance MUST: All users governed under USERS/ via SERVICES/USER MUST: Cross-index INTEL across users (INTEL.md) MUST: Shared events propagate to ALL affected user dashboards MUST: Maintain governance workspace purity (.md files only) MUST: Ledger all COIN (validated work) through MAGIC 255 MUST: Compile all INTEL from governed sources MUST: Keep frontend/runtime implementation under ~/.canonic (hidden runtime) MUST: Surface governed TALK, Library, and SERVICES scopes (no orphan content) MUST: Derive nav labels from governed scope names (no hardcoded strings) MUST NOT: Publish without governance (CANON.md required) MUST NOT: Duplicate primitives — compose from INTEL, CHAT, COIN MUST NOT: Silo intelligence inside a single user when multiple are affected MUST NOT: Expose VAULT contents outside NDA scope MUST NOT: Store runtime artifacts in governance workspace
canonic-canonic
SPEC is governance. `canonic-canonic/` is the spec root.
MUST: Keep this repo governance-only (.md/.pdf) MUST: Publish workspace mapping in CANONIC.git (no hardcoded repo lists) MUST: Preserve three primary lanes: FOUNDATION, INDUSTRIES, MAGIC MUST NOT: Commit runtime artifacts here (runtime belongs in ~/.canonic/) MUST: Sell MAGIC tiers — the product, not the proof (proof is hadleylab-canonic) MUST NOT: Embed beta-test app URLs in platform page content