THE LIFE GRAPH ARCHITECTURE

Foundational Graph Architecture for Human-Centered Intelligence

Instrument: The Life Graph Architecture

Function: Canonical graph architecture powering contextual intelligence across the Keyra Companion Ecosystem

Version: 1.0 (Founding Architecture)

Status: Subordinate to the Human Sovereignty Charter; governed by the Companion Charter, Life Operating System, and Human Digital Twin Architecture

Core constraint: The Life Graph belongs to the human. Applications do not own it. The Companion interprets it. Agents operate within it.

Preamble

A human life is not a collection of records in disparate databases. It is not a customer profile optimized for conversion. It is not a social network graph owned by a platform. It is not a knowledge base extracted for institutional advantage. It is a woven fabric of relationships, commitments, assets, memories, goals, permissions, and time — continuously evolving, asymmetrically weighted, and irreducibly personal.

Yet intelligent assistance — companions, agents, family coordination, organizational participation — requires structure. Structure that respects sovereignty. Structure that models reality as the human experiences it, not as applications partition it. Structure that persists across devices, decades, and domains without surrendering ownership to any host.

This document defines the Life Graph — the foundational graph architecture that powers Keyra Companion, Human Digital Twin, Family Trust Network, Organization Graph, Trust Vault, KAAI, the Agent Ecosystem, and the Global Trust Network.

The Life Graph is the contextual intelligence layer of the Human Sovereignty Operating System. It models reality around the human. It does not belong to applications. It belongs to the human. The human owns their Life Graph. The Companion interprets the Life Graph. Agents operate within the Life Graph.

PART I — Definition

Section 1.01 — What Is a Life Graph?

A Life Graph is a sovereign, temporally ordered, multi-typed property graph representing a human's authorized digital existence — comprising nodes for people, assets, organizations, goals, memories, devices, and agents; edges for relationships, ownership, authorization, trust, dependency, and time; and metadata for provenance, versioning, lifecycle state, and permission scope.

The Life Graph is:

• Human-owned — the Sovereign Human holds root authority over the graph and all subgraphs derived from it
• Contextual — every node and edge carries situational meaning relative to the human's present, past, and authorized future
• Integrative — domains (family, health, career, wealth, travel, community, legacy) connect through cross-domain edges rather than siloed schemas
• Temporal — history is first-class; the graph answers what was true, what is true, and what is planned under human authorization
• Permission-governed — visibility, editability, and agent action derive from explicit authorization records embedded in the graph
• Inspectable — the human may traverse, query, export, and audit the full graph or any subgraph
• Portable — the graph exports in standard graph interchange formats with provenance intact

The Life Graph is the machine-readable autobiography of authorized digital life — the substrate upon which Life Intelligence operates.

Section 1.02 — What Is Not a Life Graph?

A Life Graph is not:

• A vendor database — rows and tables owned by a platform, subject to terms-of-service forfeiture
• A CRM system — a commercial object model treating humans as leads, opportunities, and lifetime value scores
• A social graph — a platform-owned network optimized for engagement extraction and advertising targeting
• A generic knowledge graph — an institutional ontology divorced from human sovereignty and permission scope
• A digital twin alone — the Twin is a representation layer; the Life Graph is the integrative record and relationship substrate upon which the Twin is built
• An activity log — a flat chronological stream without relational, trust, and authorization semantics
• An application state store — session data, UI preferences, and feature flags scoped to a single product

If it cannot be exported by the human, it is not a Life Graph. If it cannot be deleted by the human, it is not sovereign. If applications own the schema, it is not human-centered. If agents write without authorization edges, it is not governed.

Section 1.03 — Distinctions Among Graph-Like Systems

Database

A database stores records in tables or documents optimized for application queries. Ownership typically resides with the application operator. Schema changes serve product roadmaps, not human life arcs. Relationships are foreign keys — syntactic, not semantic. Temporal history is optional, often truncated. Authorization is application-level role-based access control, not human-granted, revocable, exportable permission chains.

The Life Graph may be persisted in database engines, but it is not defined by them. The Life Graph is a semantic model; databases are storage substrates.

CRM (Customer Relationship Management)

A CRM represents humans to vendors — purchase history, support interactions, marketing segments, pipeline stages. The human is the object of commercial relationship. Data flows inward for extraction; portability is adversarial. CRM conflates identity with commercial behavior and optimizes vendor revenue, not human flourishing.

The Life Graph inverts this asymmetry. Commercial relationships may appear as Organization nodes and authorized transaction edges — but the human is the subject, not the record.

Social Graph

A social graph maps connections on a platform — friends, followers, blocks — owned by the platform, optimized for feed ranking and ad targeting. Edges are symmetric or asymmetric per platform policy, not per human-declared trust. Leaving the platform fragments or forfeits the graph.

The Life Graph includes social relationships as Human nodes and relationship edges with trust weights, authorization scopes, and temporal evolution — all exportable with the human.

Knowledge Graph

A knowledge graph encodes entities and relations for institutional reasoning — products, geographies, concepts, publications. It serves organizational intelligence. Humans appear as entities among others, without sovereign ownership of the graph.

The Life Graph is a personal knowledge graph — ontology centered on one Sovereign Human, with institutional entities appearing only as authorized Organization nodes. The human owns the ontology scope.

Digital Twin

The Human Digital Twin is the integrated, layered representation of a person — identity, preferences, goals, context, memory, decisions, trust, emotional indicators, predictions. The Twin answers who is this human, digitally?

The Life Graph is the persistent, relational, temporal substrate — the graph of nodes and edges that the Twin reads, writes, and integrates. The Twin is the lens; the Life Graph is the territory. Twin layers map to Life Graph node and edge types; Twin governance maps to Life Graph authorization and provenance records.

Section 1.04 — Why a Life Graph Is Required

Humans require a Life Graph because:

Without a Life Graph, companions revert to stateless assistants. With it, the ecosystem achieves Life Intelligence — contextual understanding without usurping human authority.

Section 1.07 — The Life Graph in the Ecosystem Stack

The Life Graph sits at the center of the Human Sovereignty Operating System stack:

┌─────────────────────────────────────────┐
│     Human Sovereignty Charter (law)      │
├─────────────────────────────────────────┤
│     Companion Charter (relationship)     │
├─────────────────────────────────────────┤
│     Life Operating System (domains)      │
├─────────────────────────────────────────┤
│     Human Digital Twin (representation)  │
├─────────────────────────────────────────┤
│     LIFE GRAPH (contextual substrate)    │  ← this document
├─────────────────────────────────────────┤
│  Companion · Agents · Vault · KAAI       │
└─────────────────────────────────────────┘

Applications read and write through the graph API under authorization — they do not define the graph. The Twin layers are views and enrichments atop graph nodes. The Life Operating System domains tag and organize graph regions.

Section 1.08 — Historical Failure Modes

Prior systems failed because they:

The Life Graph architecture responds to each failure mode with an explicit design countermeasure.

Section 1.09 — Relationship to the Human Digital Twin

The Twin and Life Graph are complementary:

Twin layers project from graph nodes. Human edits may update both — correction propagates to graph source nodes; Twin projections refresh. Twin without Life Graph lacks persistence and provenance. Life Graph without Twin lacks interpretive depth for Companion reasoning.

Section 1.10 — Architectural Scope

This document defines the Life Graph architecture powering:

Section 1.11 — Document Map

PART II — Foundational Principles

Section 2.01 — Human-Owned

The Sovereign Human holds root authority over the Life Graph. No application, organization, or agent may claim ownership of the graph or any subgraph by virtue of hosting, processing, or displaying it. Hosting is tenancy, not ownership. Terms of service may not forfeit graph sovereignty.

Section 2.02 — Portable

The human may export the full Life Graph or any authorized subgraph at any time, in standard graph interchange formats (JSON-LD, GraphML, or successor standards), with provenance metadata intact. Portability is not a feature — it is a constitutional requirement per the Human Sovereignty Charter.

Section 2.03 — Inspectable

Every node, edge, attribute, and metadata field is traversable by the human. The Companion presents graph contents in human-readable form. Hidden inference — models the human cannot inspect — may not override explicit graph records without authorization.

Section 2.04 — Editable

The human may create, modify, and annotate any node or edge they own or are authorized to edit. Corrections prevail over inferred values. Edit history is preserved in provenance chains unless the human authorizes compaction.

Section 2.05 — Deletable

The human may delete nodes, edges, and subgraphs without penalty. Deletion cascades follow human-defined policies — not vendor retention schedules. Tombstone records may remain for audit where the human authorizes; otherwise, erasure is complete.

Section 2.06 — Permission-Based

No read, write, or agent action occurs without an authorization edge linking an actor to a scope. Default is deny. Permissions are granular, time-bounded, and revocable.

Section 2.07 — Context-Aware

Nodes and edges carry context attributes — domain tags, situational weights, active/inactive flags. The Companion weights graph traversal by present context per Life Operating System rules.

Section 2.08 — Time-Aware

Every mutation is timestamped. Historical states are queryable. Future intentions appear as authorized intent nodes with validity windows — not as executed fact until human confirmation.

Section 2.09 — Relationship-Aware

Edges encode relationship type, direction, strength, and asymmetry. The graph preserves power dynamics — guardian to ward, manager to report — without flattening them.

Section 2.10 — Authorization-Aware

Authorization is not an afterthought bolted onto storage. Authorization edges are first-class graph citizens, queryable alongside relationship and trust edges.

Section 2.11 — Trust-Aware

Trust weights modulate visibility, delegation depth, and agent autonomy. Low-trust paths require additional authorization. Trust decay and repair are modeled explicitly.

Section 2.12 — Principle Hierarchy

When principles conflict, resolution order is:

Section 2.13 — Operational Implications

Each principle imposes implementation obligations:

Human-owned requires export APIs, prohibition on vendor lock-in clauses, and legal clarity that hosting does not convey ownership.

Portable requires graph interchange standards compliance and migration tooling that preserves provenance.

Inspectable requires human-readable graph browsers, LGQL explanation, and provenance chains on all inferred values.

Editable requires conflict resolution favoring human explicit edits over model inference.

Deletable requires cryptographic erasure options for Vault-linked content and tombstone policies.

Permission-based requires default-deny middleware on every graph operation.

Context-aware requires Context Engine integrations on all Companion-facing queries.

Time-aware requires versioned storage and interval-indexed edges.

Relationship-aware requires directed, weighted, asymmetric edge support — not undirected simplification.

Authorization-aware requires Authorization Engine as mandatory gate — not optional plugin.

Trust-aware requires Trust Engine integrations with decay, repair, and revocation — not static ACLs.

These obligations are non-negotiable for implementations claiming Life Graph compliance.

PART III — Graph Ontology

Section 3.01 — Ontology Design Philosophy

The Life Graph ontology is human-centered, extensible, and versioned. Core node and edge types are normative for interoperability. Extensions require namespace declaration and must not override core sovereignty semantics.

Section 3.02 — Node Types

All nodes inherit base attributes defined in Section 3.04.

Section 3.03 — Edge Types

Section 3.04 — Base Node Attributes

Every node carries:

id: UUID (immutable)
type: NodeType
created_at: ISO 8601
updated_at: ISO 8601
created_by: ActorRef (human, agent, or system under grant)
owner: SovereignHumanRef
visibility: enum [private, family, organization, public_authorized]
lifecycle_state: enum [active, dormant, archived, deleted_tombstone]
version: integer
provenance: ProvenanceChain
domain_tags: string[] (family, health, learning, career, wealth, travel, community, legacy)

Section 3.05 — Base Edge Attributes

Every edge carries:

id: UUID
type: EdgeType
source: NodeRef
target: NodeRef
created_at: ISO 8601
valid_from: ISO 8601 (optional)
valid_until: ISO 8601 (optional)
weight: float 0.0–1.0 (optional, semantic per edge type)
bidirectional: boolean
authorization_ref: AuthorizationRef (required for agent-created edges)

Section 3.06 — Metadata

Metadata layers attach without altering core semantics:

• Provenance — origin, transformations, agents involved
• Annotation — human notes, Companion summaries (labeled as inferred)
• Compliance — regulatory tags where applicable
• Localization — display labels per language

Section 3.07 — Inheritance

Node types may inherit attribute schemas:

• Human extends base with identity, contact, role attributes
• Asset.Financial extends Asset with account identifiers (encrypted refs to Trust Vault)
• Agent.Companion extends Agent with bond and succession attributes

Inheritance is schema inheritance, not authority inheritance. Authority flows only through explicit authorization and trust edges.

Section 3.08 — Versioning

Nodes version on material change. Version chains link via preceded_by edges. The human may query any historical version. Compaction policies require human authorization.

Section 3.09 — Lifecycles

Lifecycle transitions are events in the Time Graph.

Section 3.10 — Temporal Relationships

Temporal edges bind nodes to intervals:

• valid_from / valid_until on edges
• Intent nodes for future commitments
• Memory nodes with occurred_at and duration

Temporal reasoning uses interval algebra — overlap, containment, succession — for conflict detection.

Section 3.11 — Trust Relationships

Trust edges are directed and weighted. Trust may be mutual or asymmetric. Trust policies attach as TrustRecord nodes referencing edge sets.

Section 3.12 — Authorization Relationships

Authorization edges form DAGs from Sovereign Human root. Delegation extends chains with depth limits. Revocation creates superseding Authorization nodes — never silent deletion.

Section 3.13 — Supplementary Node Types

Beyond core types, the ontology includes:

Place nodes connect to Memory events (occurred_at), Asset nodes (located_at), and Goal nodes (target_location). Obligation nodes bridge Goals and Authorization — an overdue obligation triggers Attention queries without autonomous payment.

Section 3.14 — Cross-Domain Edges

The Life Operating System defines eight domains. Cross-domain edges explicitly link nodes across domains:

• Health Goal —conflicts_with→ Travel Goal
• Career Obligation —competes_for_time→ Family Goal
• Wealth Asset —funds→ Learning Goal
• Community Memory —supports→ Legacy Goal

Without cross-domain edges, companions reason in silos. With them, Life Intelligence answers integrative questions the Life Operating System demands.

Section 3.15 — Namespace and Extension

Extensions declare namespace URIs under human control. Example: keyra:core for normative types; human:custom for personal extensions. Extensions may add node subtypes and edge types but may not:

• Override ownership semantics
• Bypass authorization requirements
• Remove provenance fields
• Claim root authority over Self

Namespace registration is a graph event — auditable, revocable.

Section 3.16 — Provenance Chain Schema

Every mutation appends to provenance:

{
  "event_id": "uuid",
  "timestamp": "ISO 8601",
  "actor": { "type": "Human|Agent", "ref": "uuid" },
  "authorization_ref": "uuid",
  "operation": "create|update|delete|merge",
  "input_hash": "sha256",
  "previous_version": "integer"
}

Provenance enables forensic audit — who changed my graph, when, under what grant — per Human Sovereignty Charter transparency requirements.

Section 3.17 — Graph Validation Rules

Implementations must enforce:

Validation runs on write and on export to catch corruption early.

PART IV — Human Nodes

Section 4.01 — The Self Node

The Self node is the graph root — the Sovereign Human. All other nodes connect directly or indirectly to Self. Self carries:

• Legal and preferred names
• Aliases and pronouns
• Citizenship and residency (as authorized)
• Languages
• Life stage markers
• Link to Human Digital Twin identity layer

There is exactly one Self node per Life Graph instance.

Section 4.02 — Family

Family Human nodes connect via relationship edges with subtypes: parent, child, sibling, spouse, partner, extended family. Edges carry:

• closeness_weight — human-declared or Companion-inferred (labeled)
• contact_frequency — derived from authorized activity
• emergency_priority — human-designated
• inheritance_role — beneficiary, executor, guardian nominee

Section 4.03 — Friends

Friends nodes use relationship subtype friend with trust edges typically higher than acquaintances but without legal dependency unless authorized.

Section 4.04 — Colleagues

Colleagues connect via Organization membership shared edges. Relationship edges may be colleague, manager, report, mentor, mentee. Authority asymmetry is preserved.

Section 4.05 — Advisors

Advisors — financial, legal, medical, spiritual — carry advisor subtype with scoped authorization edges defining what domains they may access.

Section 4.06 — Dependents

Dependents are Human nodes for whom Self holds guardianship or financial responsibility. dependency edges link Self to Dependent with obligation metadata.

Section 4.07 — Guardians

Guardians are Human nodes authorized to act on behalf of Self or Dependents under guardianship agreements — modeled as authorization chains with legal scope references.

Section 4.08 — Mentors

Mentors connect via mentor relationship edges, often cross-linked to Learning goals and Career goals.

Section 4.09 — Human Node Schema

{
  "type": "Human",
  "subtype": "family|friend|colleague|advisor|dependent|guardian|mentor|self",
  "names": { "legal": "", "preferred": "", "aliases": [] },
  "contact_refs": ["encrypted_contact_id"],
  "twin_identity_ref": "uuid",
  "relationship_to_self": "edge_ref"
}

Section 4.10 — Trust Models for Humans

Trust toward Human nodes uses graduated scales:

• Intimate trust (0.85–1.0) — family, lifelong friends; broad family subgraph visibility
• Professional trust (0.6–0.85) — colleagues, advisors; domain-scoped
• Acquaintance trust (0.3–0.6) — limited visibility
• Unknown (<0.3) — minimal default; explicit authorization required

Trust scores are advisory to the Companion — not autonomous access control without authorization edges.

Section 4.11 — Relationship Models

Relationships evolve through states: forming, stable, strained, dormant, ended. State transitions are Memory events. The Companion surfaces relationships changing when state or trust derivative exceeds thresholds — for human reflection, not autonomous intervention.

Section 4.12 — Human Centrality Metrics

Graph centrality informs Companion prioritization but does not override human designation:

• Degree centrality — count of relationship edges
• Weighted centrality — sum of closeness × trust
• Emergency centrality — human-flagged contacts regardless of frequency
• Dependency centrality — Dependents and Guardians weighted for duty-of-care alerts

Centrality scores are labeled inferred in Companion presentation. Human may pin or exclude contacts from centrality rankings.

Section 4.13 — Multi-Graph Human Identity

The same natural person may appear as Human nodes in multiple Life Graphs — Self's graph, family member's graph, colleague's graph. Global identity resolves through federated identifiers (authorized, opt-in) without merging graphs without consent. Each graph instance maintains sovereign perspective — relationship edge from Self to Colleague differs from Colleague's graph view of Self.

Section 4.14 — Privacy Tiers for Human Nodes

Tier escalation requires human action. Companion may suggest tier review after life events — marriage, job change — never auto-escalate.

PART V — Asset Nodes

Section 5.01 — Asset Taxonomy

Section 5.02 — Ownership Structures

ownership edges link Human or Organization to Asset:

• Sole ownership — single owner node
• Joint ownership — multiple owners with percentage attributes
• Beneficial ownership — legal vs beneficial owner distinction where authorized

Section 5.03 — Trust Structures

Assets may be held in trust — Trust Organization node with governs edge to Asset subset. Beneficiaries connect via inherits_from edges with conditions.

Section 5.04 — Authorization Structures

Asset access for agents requires explicit authorization:

• Read balance — Finance Agent, time-bounded
• Execute transfer — requires approval chain edge
• Document retrieval — scoped to document type

Sensitive values never store in graph plaintext — only Trust Vault references.

Section 5.05 — Asset Lifecycle

Assets transition: acquired, active, maintained, transferred, disposed. Each transition is a Memory event with provenance.

Section 5.06 — Asset Valuation and Risk

Financial Asset nodes may link to market data feeds under Finance Agent authorization. Valuation snapshots timestamp as Memory events — not live balance in graph plaintext. Risk edges connect Assets to Goals (endangers retirement goal if concentration exceeds policy) and Obligations (secures mortgage obligation).

Section 5.07 — Document and Credential Linkage

Document assets carry governs edges to Assets they legally affect — deed to Home, title to Vehicle. Credential assets link to Authorization scopes — medical license enables Health Agent advisory subset. Trust Vault stores blobs; graph stores metadata and refs only.

Section 5.08 — Digital Asset Provenance

Digital assets — domains, cryptocurrency wallets, media — require provenance chains for transfer authenticity. Agent-initiated transfers require approval chains proportional to asset tier.

PART VI — Organization Nodes

Section 6.01 — Organization Types

Section 6.02 — Governance Models

Organizations carry governance attributes:

• authority_structure — hierarchical, flat, board-governed
• decision_makers — Human nodes with role edges
• policies — links to Document assets

Section 6.03 — Membership Models

membership edges link Human to Organization:

• role — employee, student, member, officer
• start_date, end_date
• authority_level — numeric rank within org graph

Section 6.04 — Authority Models

governs edges from Organization to subgraphs — project nodes, department nodes, agent deployments. Authority never supersedes human sovereignty — org graphs operate within human-authorized participation boundaries.

PART VII — Goal Nodes

Section 7.01 — Goal Taxonomy

Section 7.02 — Goal Attributes

horizon: daily|weekly|monthly|annual|lifetime
priority: integer 1–10
status: proposed|active|paused|completed|abandoned
progress: 0.0–1.0
target_date: ISO 8601 (optional)

Section 7.03 — Goal Dependency Models

dependency edges: Goal B cannot complete until Goal A reaches state. Dependencies form DAGs. Cycle detection triggers Companion alert — circular goal dependency detected.

Section 7.04 — Goal Conflict Models

conflict edges link mutually exclusive goals — e.g., aggressive travel goal vs health recovery goal. Conflict severity derives from priority product and temporal overlap.

Section 7.05 — Priority Models

When resources (time, money, attention) are insufficient, the Goal Engine resolves conflicts by:

Resolution suggests — never executes reallocation without authorization.

PART VIII — Memory Nodes

Section 8.01 — Memory Taxonomy

Section 8.02 — Memory Relationships

Memories connect via:

• involves — Human, Place, Organization participants
• preceded_by — narrative sequence
• related_to — thematic linkage
• occurred_during — Time interval
• supports_goal — Goal progress evidence

Section 8.03 — Memory Importance Models

Importance score (0.0–1.0) derives from:

• Human explicit marking
• Emotional salience indicators (non-clinical, authorized)
• Goal linkage strength
• Relationship centrality of participants
• Recency with decay function

High-importance memories resist automated compaction.

Section 8.04 — Memory Inheritance Models

inherits_from edges define Legacy tier access:

• Family archive beneficiaries
• Embargo until date
• Redaction rules for third-party privacy

Inheritance executes per Legacy Graph policies — Part XVII.

PART IX — Device Nodes

Section 9.01 — Device Taxonomy

Section 9.02 — Device Trust Graph

Devices earn trust scores based on:

• Hardware attestation (Keyra Key binding)
• Patch currency
• Compromise indicators
• Physical possession signals

Low-trust devices restrict authorization scope — sensitive subgraphs require Keyra Key presence.

Section 9.03 — Device Authority Graph

hosted_on edges link agents and data replicas to devices. authorization edges scope which agents may run on which devices.

Section 9.04 — Device Ownership Graph

ownership edges link Human to Device. Shared family devices carry multi-owner edges with usage policies.

PART X — Agent Nodes

Section 10.01 — Agent Taxonomy

Section 10.02 — Agent Authority Models

Each agent carries:

max_autonomy_level: 0–5 (0=read only, 5=execute with post-hoc audit)
authorized_domains: string[]
authorized_node_patterns: graph query scope
approval_required_above: monetary or risk threshold

Section 10.03 — Agent Trust Models

Agents inherit trust ceiling from delegating human. Agent-to-agent delegation requires explicit delegates_to with reduced scope. Agents may not exceed grant.

Section 10.04 — Agent Expiration Models

Every agent authorization carries valid_until. Expired agents transition to dormant — retained for audit, inactive for action. Renewal requires human confirmation.

Section 10.05 — Agent Delegation Models

Delegation chains:

Self → Companion → FinanceAgent → (no further without re-grant)

Maximum depth configurable per human policy. Each hop logs provenance.

Section 10.06 — Agent Lifecycle in the Graph

Agent nodes traverse lifecycle states parallel to Human Digital Twin lifecycle:

Companion Agent has special lifecycle — bond edges to Self, succession edges to Legacy Graph.

Section 10.07 — Agent-to-Agent Protocol

Agents communicate through graph-mediated message nodes — not side channels. Each message node carries authorization_ref, sender Agent, recipient Agent, scope. Unauthorized agent messages rejected at write. Audit reconstructs inter-agent coordination.

Section 10.08 — Government Agent Constraints

Government Agent subtype operates under strictest constraints — scope limited to explicit civic filings human authorized, no speculative data gathering, mandatory transparency log exportable to human, automatic expiration per regulatory session.

PART XI — Authorization Graph

Section 11.01 — Authorization Architecture

The Authorization Graph answers:

• Who may act? — Actor node (Human, Agent)
• What may they do? — Action enum: read, write, execute, delegate, export, delete
• Under what conditions? — Device trust, time window, approval chain
• For how long? — valid_until
• For whom? — Scope: node pattern, subgraph, domain tag

Section 11.02 — Authorization Chains

Chains form trees rooted at Self. Each grant references parent authorization. Revocation at any ancestor invalidates descendants unless independently re-authorized.

Section 11.03 — Approval Chains

High-risk actions require approval edges through designated Human nodes — e.g., transfers above threshold require spouse approval.

Section 11.04 — Delegation Chains

Delegation reduces scope monotonically. A delegate may not grant broader scope than received.

Section 11.05 — Emergency Overrides

Emergency authorization templates — medical crisis, incapacity — pre-authorized by human with:

• Trigger conditions
• Scope limitation
• Automatic expiration
• Post-event audit requirement

Section 11.06 — Revocation Models

Revocation creates superseding Authorization node with effect: revoke, target: original_grant_id, timestamp. Propagation is immediate. Agents mid-action must halt and log partial state.

Section 11.07 — Authorization Node Schema

{
  "type": "Authorization",
  "grantor": "SovereignHumanRef",
  "grantee": "ActorRef",
  "actions": ["read", "write", "execute", "delegate", "export"],
  "scope": {
    "node_pattern": "LGQL pattern",
    "domain_tags": ["health", "wealth"],
    "subgraph_root": "NodeRef"
  },
  "conditions": {
    "min_device_trust": 0.8,
    "requires_approval_from": ["HumanRef"],
    "time_window": { "valid_from": "", "valid_until": "" }
  },
  "parent_grant": "AuthorizationRef",
  "effect": "grant|revoke",
  "revokes": "AuthorizationRef"
}

Section 11.08 — Conditional Authorization

Conditions evaluate at query time:

• Device trust — grant inactive on untrusted device
• Geofence — health data readable only in home country if human sets policy
• Dual control — financial execute requires two Human approvals within time window
• Purpose binding — agent may read travel documents only while Travel Goal active

Failed condition returns authorization_denied with reason code — inspectable by human.

Section 11.09 — Authorization Audit Trail

Every authorization check logs:

timestamp, actor, action, target_node, grant_id, result, condition_failures[]

Audit subgraph is append-only for human inspection. Companion summarizes weekly authorization activity.

Section 11.10 — Default Deny Posture

Absence of authorization edge means deny. Implicit platform permissions are architecturally prohibited. Companion bootstrap receives minimal grant — expand only by human confirmation.

PART XII — Trust Graph

Section 12.01 — Trust Relationships

Trust is directed, weighted, and typed:

• interpersonal — Human to Human
• institutional — Human to Organization
• device — Human to Device
• agent — Human to Agent

Section 12.02 — Trust Scoring

Base trust \( T \in [0, 1] \). Initial values human-declared or default 0.5 for new edges.

Update function (simplified):

\[ T_{t+1} = \alpha \cdot T_t + (1 - \alpha) \cdot E_t \]

Where \( E_t \) is evidence from authorized interactions (positive or negative) and \( \alpha \) is decay-retention factor (default 0.95).

Section 12.03 — Trust Inheritance

Family trust networks may inherit baseline trust:

\[ T_{inherit} = \min(T_{parent} \cdot \beta, T_{max\_inherit}) \]

With \( \beta \in (0, 1) \) typically 0.7 — trust does not fully transfer without direct relationship.

Section 12.04 — Trust Decay

Without reinforcing evidence:

\[ T_t = T_0 \cdot e^{-\lambda \Delta t} \]

Decay rate \( \lambda \) configurable per relationship subtype.

Section 12.05 — Trust Repair

Negative events apply penalty \( \Delta T_{neg} \). Repair requires explicit human acknowledgment and positive evidence series — modeled as TrustRepair Memory events.

Section 12.06 — Trust Delegation

Delegating authority to agent A for interaction with human H requires:

\[ T_{effective} = T_{Self \rightarrow A} \cdot T_{Self \rightarrow H} \]

Section 12.07 — Trust Revocation

Trust revocation sets \( T = 0 \) and severs authorization edges dependent on that trust threshold.

Section 12.08 — Trust Propagation

For path \( A \rightarrow B \rightarrow C \):

\[ T_{A \rightarrow C}^{path} = T_{A \rightarrow B} \cdot T_{B \rightarrow C} \cdot \gamma^{d-1} \]

Where \( d \) is path length and \( \gamma \) is dampening factor (default 0.8). Propagation informs suggestions — not automatic access.

Section 12.09 — Graph Algorithms

• Trusted subgraph extraction — BFS with trust threshold cutoff
• Anomaly detection — sudden trust drops trigger audit
• Community trust — aggregate metrics for Community Graph (opt-in)

Section 12.10 — Trust Graph Architecture

The Trust Graph is a labeled subgraph of all trust edges plus TrustRecord policy nodes. It integrates with Authorization Graph: grants may specify min_trust_threshold toward target entity before delegation activates.

Section 12.11 — Evidence Types

Trust updates consume authorized evidence:

Evidence from unauthorized surveillance is inadmissible — cannot update trust.

Section 12.12 — Worked Example: Trust Propagation

Self trusts Colleague A at 0.8. A trusts Vendor B at 0.7. Path length 2, γ=0.8:

\[ T_{Self \rightarrow B}^{path} = 0.8 \times 0.7 \times 0.8 = 0.448 \]

Below typical delegation threshold 0.5 — Companion recommends direct trust establishment before Finance Agent engages B. Propagation informs; human decides.

Section 12.13 — Trust Repair Protocol

Section 12.14 — Institutional Trust

Organization trust differs from interpersonal — based on contract fulfillment, regulatory standing, breach history. Institutional trust gates Organization subgraph federation depth.

PART XIII — Time Graph

Section 13.01 — Temporal Dimensions

Section 13.02 — Historical Context

Queries at time \( t \) reconstruct graph state \( G_t \) from version chains and edge validity windows.

Section 13.03 — Current Context

Context engine weights nodes by:

• Calendar position
• Location (authorized)
• Active projects and obligations
• Recent Memory salience

Section 13.04 — Predicted Context

Non-binding predictions — travel arrival, meeting end — as Intent nodes with confidence scores. Never executed without confirmation.

Section 13.05 — Future Intentions

Intent nodes carry status: intended|scheduled|confirmed|cancelled.

Section 13.06 — Future Commitments

Commitments link Intent to Goal and Authorization — e.g., scheduled payment requires Finance Agent grant valid through date.

Section 13.07 — Temporal Reasoning Architecture

Operations:

• Overlap detection — scheduling conflicts
• Precedence — dependency satisfaction
• Decay — stale Intent expiration
• Rollback — what did the graph look like on date X?

PART XIV — Family Graph

Section 14.01 — Family Architecture

The Family Graph is a subgraph of the Life Graph with shared visibility policies governed by Family Trust Network charter (future instrument).

Section 14.02 — Generational Structure

Nodes: Parents, Children, Grandparents, Siblings, Extended. Edges preserve lineage direction for inheritance reasoning.

Section 14.03 — Guardians and Dependents

Guardianship authorization subgraphs nest under Dependent nodes. Ward privacy rules restrict guardian visibility by age and capacity.

Section 14.04 — Inheritance

inherits_from edges connect Legacy assets and Memory archives to beneficiaries with conditions (age, event-triggered).

Section 14.05 — Family Permissions

Shared calendars, locations (opt-in), emergency contacts — each an authorization edge with family scope tag.

Section 14.06 — Family Trust

Inter-family trust edges aggregate for Family Trust Network federation — without exposing individual trust scores without consent.

Section 14.07 — Family History

FamilyStory and Milestone memories form narrative chains — preceded_by across generations.

Section 14.08 — Family Memory

Collective albums, reunion events — multi-owner Memory nodes.

Section 14.09 — Family Legacy

Succession plans linking Companion succession, archive beneficiaries, and values documents.

Section 14.10 — Blended and Chosen Family

Family Graph explicitly supports non-biological family — relationship subtypes include chosen_family, step_parent, guardian_by_choice. Lineage edges optional; legal edges reference Document assets where authorized. Architecture refuses biological essentialism — family is human-declared.

Section 14.11 — Minor and Incapacity Protections

Dependent minors' subgraphs carry elevated privacy defaults. Guardian authorization narrows at age milestones per human policy. Incapacity triggers pre-authorized emergency subgraph per Authorization Graph Section 11.05 — never platform-defined conservatorship.

Section 14.12 — Family Conflict Resolution

Conflicting family authorizations — divorced parents, competing guardians — resolve through explicit court Document nodes or human mediation records. Companion presents conflict; does not adjudicate. Graph holds parallel authorization chains with scope tags until human resolution.

PART XV — Organization Graph

Section 15.01 — Enterprise Graph Architecture

Organization Graph extends Life Graph with employer-specific nodes — not owned by employer, participated in by human.

Section 15.02 — Employees and Departments

Department nodes form tree under Organization. Human nodes connect via membership with department attribute.

Section 15.03 — Projects

Project nodes link Humans, Goals, Documents, and Work Agents. part_of edges compose project hierarchy.

Section 15.04 — Authority Structures

Role-based edges: reports_to, approves_for, delegates_authority. Org authority stops at organization boundary — never root over Life Graph.

Section 15.05 — Approvals

Workflow templates as subgraphs — purchase approval, time-off — instantiated with authorization chains.

Section 15.06 — Responsibilities

Obligation nodes link Human to deliverables with deadlines — queryable for obligations overdue.

Section 15.07 — Companions and Agents at Work

Work Agent scope limited to Organization subgraph. Employer may not access personal family subgraph without separate grant.

Section 15.08 — Organizational Knowledge

Document and expertise nodes — who knows what — for internal discovery, exportable when human leaves organization.

PART XVI — Community Graph

Section 16.01 — Social Context Architecture

Community Graph models voluntary associations beyond family and employer.

Section 16.02 — Neighborhoods and Communities

Place-linked community nodes — neighborhood association, HOA — with membership edges.

Section 16.03 — Memberships

Clubs, gyms, co-working spaces — membership edges with renewal dates.

Section 16.04 — Volunteer Groups

Volunteer Goal nodes link to Organization nonprofit nodes.

Section 16.05 — Professional Networks

LinkedIn-equivalent as owned relationship edges — not platform hostage.

Section 16.06 — Religious Communities

Religious Organization nodes with participation and role edges.

Section 16.07 — Shared Interests

Interest tags form virtual communities — Humans connected via shared_interest edges without central platform.

PART XVII — Legacy Graph

Section 17.01 — Legacy Preservation Architecture

Legacy Graph activates when human enters legacy lifecycle stage or upon death — per Human Sovereignty Charter inheritance provisions.

Section 17.02 — Digital Inheritance

Beneficiary authorization templates activate on trigger event. Companion succession transfers to designated heir or archival mode.

Section 17.03 — Family and Personal Archives

Memory subsets tagged legacy_tier with inheritance edges.

Section 17.04 — Historical Memory

Irreducible life record — human curates what persists for descendants.

Section 17.05 — Values

Values nodes — declarative statements linked to Goals and Life Lessons — guide Companion succession behavior.

Section 17.06 — Instructions

Executable instructions — funeral wishes, asset distribution — as Document nodes with trigger conditions.

Section 17.07 — Knowledge Transfer

Expertise maps for profession, family recipes, institutional memory — structured for beneficiary access.

Section 17.08 — Companion Succession

Companion Agent node receives succession authorization — new bond with beneficiary, prior bond archived.

Section 17.09 — Legacy Activation Triggers

Legacy Graph transitions activate on:

• Human-declared legacy lifecycle stage
• Verified death attestation (authorized document)
• Incapacity declaration per legal Document
• Scheduled date for posthumous message release

Triggers are Memory events with multi-party verification where required.

Section 17.10 — Redaction and Dignity

Legacy inheritance respects third-party privacy — conversations involving non-beneficiaries may redact. Human pre-declares redaction policies. Companion succession inherits values, not surveillance dossiers.

Section 17.11 — Multi-Generational Archives

Family archives chain across generations — grandparent Legacy Memory visible to grandchild upon age threshold. inherits_from edges may specify generational delay, educational prerequisites, or family ceremony as conditions.

PART XVIII — Life Graph Queries

Section 18.01 — Graph Reasoning Framework

Companions reason via constrained graph traversal — never unbounded inference. Query classes:

Section 18.02 — Query Language

Life Graph Query Language (LGQL) — declarative, human-inspectable:

MATCH (self:Human {subtype:'self'})-[:relationship*1..2]->(h:Human)
WHERE h.trust > 0.7 AND context.active = true
RETURN h ORDER BY h.closeness DESC LIMIT 5

LGQL translations log to provenance for transparency.

Section 18.03 — Companion Interpretation

The Companion translates LGQL results to natural language — always citing graph paths for human verification.

Section 18.04 — Safety Bounds

Queries accessing subgraphs outside authorization scope fail closed. Agents may not run arbitrary LGQL — only templates within grant.

Section 18.05 — Exemplar Queries

Who matters most?

MATCH (self:Human {subtype:'self'})-[r:relationship]->(h:Human)
WHERE r.lifecycle_state = 'active'
WITH h, r.closeness * r.trust * context.weight(h) AS score
RETURN h.names.preferred, score ORDER BY score DESC LIMIT 7

What is at risk?

MATCH (g:Goal {status:'active'})-[:conflict]->(g2:Goal)
WHERE g.priority >= 7 OR g.progress < 0.2
OPTIONAL MATCH (o:Obligation)-[:supports]->(g) WHERE o.deadline < now() AND o.status != 'complete'
RETURN g, g2, collect(o) AS overdue_support

What needs attention?

MATCH (a:Authorization {status:'pending_approval'})
MATCH (e:Authorization) WHERE e.valid_until < now() + duration('P7D')
MATCH (h:Human)-[r:relationship]->(self) WHERE r.state = 'strained'
RETURN a, e, h

Section 18.06 — Reasoning Constraints

Companions apply reasoning constraints:

• Citation requirement — every conclusion cites edge paths
• Confidence labeling — inferred vs explicit
• Recency bias disclosure — when recent memories overweight conclusions
• Abstention — insufficient graph data yields "I don't know" not fabrication

Section 18.07 — Human Digital Twin integrations

LGQL operates over Life Graph substrate; Twin layers provide derived views. Twin preference layer may suggest query weights but may not inject nodes without authorization. Twin predictive layer generates Intent candidates — human promotes to graph.

PART XIX — Graph Intelligence

Section 19.01 — Engine Architecture

Section 19.02 — Context Engine

Inputs: calendar, location (authorized), active devices, recent memories. Outputs: node and edge weight multipliers for traversal.

Section 19.03 — Relationship Engine

Processes interaction evidence, updates trust, detects state transitions, surfaces changing relationships alerts.

Section 19.04 — Goal Engine

Monitors progress, detects conflicts and dependency blockers, proposes reprioritization for human approval.

Section 19.05 — Memory Engine

Scores importance, proposes compaction of low-salience memories, respects inheritance locks.

Section 19.06 — Trust Engine

Implements mathematical frameworks from Part XII. Feeds Authorization Engine trust thresholds.

Section 19.07 — Authorization Engine

Validates every read/write/execute. Caches valid grants with TTL. Immediate invalidation on revocation.

Section 19.08 — Prediction Engine

Generates Intent nodes with confidence — schedule conflicts, budget overrun risk. Labels all outputs as predictive, not prescriptive.

Section 19.09 — Life Intelligence Engine

Orchestration pipeline:

No engine may bypass Authorization Engine. No engine may write without grant.

Section 19.10 — Engine Interaction Diagram

┌─────────────────────────────────────────────────────────────┐
│                  Life Intelligence Engine                    │
└─────────────────────────────────────────────────────────────┘
         │              │              │              │
         ▼              ▼              ▼              ▼
   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
   │ Context  │  │  Goal    │  │  Memory  │  │  Trust   │
   │ Engine   │  │  Engine  │  │  Engine  │  │  Engine  │
   └──────────┘  └──────────┘  └──────────┘  └──────────┘
         │              │              │              │
         └──────────────┴──────────────┴──────────────┘
                              │
                              ▼
                   ┌──────────────────┐
                   │ Authorization    │
                   │ Engine (gate)    │
                   └──────────────────┘
                              │
                              ▼
                      Life Graph Store

All engines read through Authorization Engine filter. Write path requires explicit grant validation before commit.

Section 19.11 — KAAI integrations

KAAI (Keyra Authenticated Artificial Intelligence) actions append to Life Graph with:

• actor: AgentRef
• kaai_attestation: signature
• authorization_ref
• action_summary

KAAI without attestation is rejected at storage layer. Audit reconstructs full agent behavior timeline.

Section 19.12 — Trust Vault integrations

Trust Vault holds secrets; Life Graph holds structure. Resolution flow:

Section 19.13 — Companion Interpretation Layer

The Companion translates engine outputs to narrative:

• Synthesis — merge multi-engine results without contradiction hiding
• Prioritization — order by human policy, not engagement optimization
• Invitation — present choices, not defaults executed
• Memory of explanation — prior explanations stored for consistency check

PART XX — Graph Storage Architecture

Section 20.01 — Storage Tiers

Section 20.02 — On-Device Architecture

Primary Life Graph replica lives on Sovereign Human's trusted device — Keyra Key attested. Hot subgraph in memory; warm in encrypted embedded graph database; cold in Trust Vault blob storage.

Section 20.03 — Synchronization Architecture

CRDT-inspired merge for authorized replicas:

• Vector clocks per node version
• Conflict resolution favors human explicit edit
• Sync only authorized subgraphs per peer relationship

Section 20.04 — Privacy Architecture

Subgraphs encrypted with keys derived from human master key. Family sharing uses pairwise key exchange. Organization data never commingles with family keys.

Section 20.05 — Encryption Architecture

• At rest: AES-256 per subgraph
• In transit: TLS 1.3+ with mutual authentication
• Vault refs: HSM or Keyra Key sealed credentials

Section 20.06 — Local Graph Implementation

On-device stack recommended layers:

Offline operation uses warm layer; sync queues mutations with vector clocks.

Section 20.07 — Family Graph Federation

Family members hold overlapping subgraph replicas. Shared nodes — Family Memory, shared Calendar Intent — synchronize via family key group. Conflicting edits surface to humans; Companion does not auto-merge relationship semantics.

Section 20.08 — Organization Graph Federation

Employer hosts organization shard; employee retains portable copy of their participation subgraph — roles, projects, approvals involving Self. Departure triggers export; employer retention governed by contract, not platform lock-in.

Section 20.09 — Backup and Succession

Encrypted backups to human-chosen locations — another device, family trustee, cold storage. Backup restore requires Keyra Key or succession authorization per Legacy Graph. Backup frequency human-configured.

Section 20.10 — Global Graph Boundaries

Global Graph contains only mutually authorized attestations — identity proofs, public professional credentials, trust network reputation scores — never full Life Graph replicas. Federation protocols must pass Human Sovereignty Charter portability review.

PART XXI — Future Scale

Section 21.01 — Scale Dimensions

Section 21.02 — Scaling Principles

Section 21.03 — Billion Companion Architecture

At planetary scale:

• Each human owns one primary shard
• Companions operate local-first with lazy federation
• Global Trust Network carries attestations, not life data
• Inter-human queries require mutual authorization — no platform-wide graph search

Section 21.04 — City and Nation Scale

At city scale, public infrastructure — transit, civic services — exposes read-only Organization and Place nodes federated into Community Graph. Humans opt in to civic participation subgraphs. No municipal entity holds Life Graph root.

At nation scale, policy frameworks — data protection, identity attestation — federate as Organization nodes under Government subtype. Cross-border Life Graph export follows Human Sovereignty Charter portability regardless of jurisdiction. Nations may regulate hosting; they may not claim ownership of citizen graphs.

Section 21.05 — Performance at Scale

Sharding strategies:

• Horizontal — partition by node type within sovereign shard
• Temporal — archive cold intervals to reduce hot set
• Domain — lazy-load domain subgraphs on context activation
• Federated — query remote shards only when authorization proves mutual access

Target: sub-second context queries on device for 10⁵ node personal graphs; federated queries complete within human-perceptible latency with progressive disclosure.

Section 21.06 — Agent Ecosystem at Scale

One billion companions implies billions of Agent nodes — each scoped, expiring, auditable. Agent registry is federated index, not centralized control plane. Agent discovery requires human authorization — no ambient agent marketplace accessing graphs without grant.

PART XXII — Closing Declaration

Section 22.01 — On Relationships and Applications

Applications come and go. They are instruments — temporary hosts of human intention. Relationships endure across applications, across decades, across generations. The Life Graph encodes relationships as first-class citizens, not as foreign keys in a vendor schema. When applications die, relationships persist in the human's graph. When platforms merge, the human exports and walks away. Relationships matter more than applications because relationships are the substance of life; applications are merely lenses.

Section 22.02 — On Context and Data

Data without context is noise. A thousand disconnected facts do not constitute understanding. The Life Graph elevates context — who, when, why, under what trust, with what authorization — above raw data accumulation. Companions do not hoard data; they interpret context. Agents do not maximize engagement; they respect scope. Context matters more than data because humans live in situations, not in spreadsheets.

Section 22.03 — On Understanding and Information

Information is abundant. Understanding is scarce. The Life Graph exists to transform authorized information into understanding — integrative, temporal, relational understanding that serves human flourishing. Graph Intelligence engines do not replace human judgment; they illuminate the graph so judgment is informed. Understanding matters more than information because the goal is not to know everything but to live well with what matters.

Section 22.04 — On Human-Centered Computing

For half a century, humans adapted to applications — learning interfaces, accepting silos, forfeiting portability, surrendering context to platforms that optimized extraction. The Life Graph inverts this covenant. The graph belongs to the human. The Companion interprets under human authority. Agents operate within granted boundaries. Organizations participate by invitation. Trust is explicit, decaying, repairable, revocable.

The Life Graph becomes the foundation of human-centered computing — not because it is novel technology, but because it encodes an ancient truth in modern form: a life is one integrated whole, and any system that serves life must model it as such.

Section 22.05 — Timeless Commitment

We declare that the Life Graph Architecture shall endure as the canonical graph framework for the Keyra ecosystem and as a reference for future human-centered intelligent systems. It is offered not as product specification but as institutional architecture — subject to amendment only in subordination to the Human Sovereignty Charter, and only to better serve the humans whose lives it exists to contextualize.

The graph belongs to the human. Always.

Section 22.06 — Invocation for Implementers

Those who implement systems upon this architecture are entrusted with a duty rare in the history of computing: to build infrastructure that serves persons, not profiles; that preserves relationships, not engagement metrics; that honors authorization, not extraction. The Life Graph is not a competitive moat. It is a covenant. Build accordingly. Every graph write path must pass through human sovereignty checks. Every query must fail closed on missing authorization. Every export must preserve provenance. These are not optional optimizations — they are the minimum conditions of legitimacy for any system claiming to implement this architecture.

Section 22.07 — Invocation for Institutions

Institutions that participate in the Keyra ecosystem — employers, schools, governments, care providers — enter as guests of human graphs, not owners of human data. Federation is invitation. Participation is revocable. The Life Graph Architecture exists to ensure that when institutions depart, humans retain the fullness of their authorized digital lives.

End of Document

The Life Graph Architecture v1.0 — Founding Architecture of the Keyra Companion Ecosystem