Axiom

CONTACTS is the resolution spine of the galaxy. Every identifier resolves to a node. Every node carries INTEL. Every service resolves through CONTACTS.

Constraints

MUST:     Read Apple Contacts via Contacts framework (CNContactStore), not direct SQLite
MUST:     Build resolution index: email→node, phone→node, name→node, linkedin→node
MUST:     Cross-reference Apple Contacts against USERS/ VITAE.md (governed identity)
MUST:     Cross-reference against SERVICES/LEARNING/ contact intelligence files
MUST:     Emit CONTACTS lane events to TIMELINE INDEX
MUST:     Provide resolution API for CALENDAR, TRANSCRIPT, EMAIL, IMESSAGE, WHATSAPP, LINKEDIN
MUST:     Resolve unmatched contacts to candidate nodes (fuzzy match, not silent drop)
MUST:     Auth-gate private contact data (phone numbers, emails, addresses)
MUST NOT: Write to Apple Contacts (read-only)
MUST NOT: Duplicate USERS/ identity governance (CONTACTS resolves, USERS/ governs)
MUST NOT: Hardcode contact mappings (discover via resolution index)
MUST NOT: Expose raw contact data to public surfaces

Capabilities

CONTACT_INGEST, CROSS_REFERENCE, ENTITY_RESOLVE, FUZZY_MATCH, RESOLUTION_INDEX, TIMELINE_EMIT

COVERAGE: 255/255

SPEC

Purpose

CONTACTS is the resolution spine of the galaxy. It reads Apple Contacts, cross-references every record against governed USERS/ identities and SERVICES/LEARNING/ intelligence files, and builds a resolution index that every other service uses to link raw identifiers to galaxy nodes. When CALENDAR sees an email in a meeting participant, when TRANSCRIPT encounters a counterparty, when EMAIL processes a sender address, they all resolve through CONTACTS.

Source

Resolution Index

The resolution index maps raw identifiers to galaxy nodes:

{
  "email": {
    "isabella@e4c.tech": "USERS/ISABELLA",
    "fatima@canonic.org": "USERS/FATIMA",
    "neil@levuka.co": "SERVICES/LEARNING/neil-sumaru"
  },
  "phone": {
    "+14075551234": "SERVICES/LEARNING/alex-evans"
  },
  "name": {
    "dexter hadley": "USERS/DEXTER",
    "neil sumaru": "SERVICES/LEARNING/neil-sumaru"
  },
  "linkedin": {
    "fatima-zahra-boukrim-75613b88": "USERS/FATIMA"
  }
}

Cross-Reference Pipeline

Apple Contacts (CNContactStore)
  → Extract (name, emails, phones, org, social, notes)
  → Normalize (lowercase emails, strip phone digits, name→slug)
  → Match against USERS/*/VITAE.md identifiers
  → Match against SERVICES/LEARNING/*.md identifiers
  → Fuzzy match unmatched (Levenshtein on name, domain on email)
  → Emit RESOLUTION-INDEX.json
  → Emit CONTACTS lane to TIMELINE

Cross-Axiomatic INTEL

When a contact resolves to a galaxy node, every service gains access to that node’s full INTEL:

Contextual Prompts

Each resolved galaxy node can generate a contextual prompt for CLAUDE:

Before meeting with {NODE}:
  - Relationship: {from INTEL}
  - Last correspondence: {from TRANSCRIPT}
  - Deal status: {from LEARNING}
  - Strategic value: {from NETWORK-MAP}
  - Upcoming: {from CALENDAR}

Ecosystem

• Upstream (read-only): Apple Contacts, USERS/ VITAE.md, SERVICES/LEARNING/ intelligence files
• Downstream (consumers): CALENDAR, TRANSCRIPT, EMAIL, IMESSAGE, WHATSAPP, LINKEDIN, STAR
• TIMELINE: CONTACTS lane emits NEW_CONTACT, UPDATED_CONTACT, RESOLVED events

INTEL

Cross-Scope Evidence

Operational Inventory

Existing Contact Infrastructure

Test

LEARNING

Patterns

ROADMAP

Now

• [ ] CALENDAR enrichment (participant.email → resolved INTEL via CONTACTS index)
• [ ] TRANSCRIPT enrichment (counterparty → resolved INTEL)
• [ ] Contextual prompts (pre-meeting briefs compiled from galaxy node INTEL)

Next

• [ ] Fuzzy matching for unresolved contacts (Levenshtein on names, domain on emails)
• [ ] Contact change detection (new contacts, updated fields, deleted contacts)
• [ ] Contacts visual surface (people browser in the galaxy)

Later

• [ ] Relationship graph visualization (cross-cluster density rendering)
• [ ] Automated VITAE.md creation for promoted candidate nodes

VOCAB

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