Skip to main content
Curia’s knowledge graph stores all long-term memory in Postgres as typed nodes and edges with temporal metadata. This page documents the data model.

​
Node types

Every node in the knowledge graph has a type field from this fixed set:
TypeDescriptionExamples
personAn individualCEO, board members, contacts
organizationA company, team, or institutionAcme Corp, Finance team
projectA project or initiativeQ3 Fundraising, Website Redesign
decisionA decision that was made”Hired Alice as CFO”, “Moved to weekly standups”
eventA meeting, conference, or occurrenceBoard meeting, Series A close
conceptAn abstract idea or topicMachine learning, Compliance policy
factA specific piece of information about an entity”Prefers morning meetings”, “Lives in Toronto”

​
Edge types

Edges represent typed relationships between nodes:
CategoryTypesDescription
Structuralworks_on, decided, attended, relates_to, belongs_to, authored, mentioned_inGeneral relationships between entities
Personalspouse, parent, child, siblingFamily relationships
Professionalreports_to, manages, collaborates_with, advises, representsOrganizational hierarchy and work relationships
Organizationalmember_of, founded, invested_inMembership and investment relationships
relates_to is the generic fallback — use it when no specific type fits.

​
Temporal metadata

Every node and edge carries temporal metadata: 
interface TemporalMetadata {
  createdAt: Date;         // when first recorded
  lastConfirmedAt: Date;   // last time evidence reinforced this
  confidence: number;      // 0–1 scale, decays over time
  decayClass: DecayClass;  // how fast confidence decays
  source: string;          // provenance: "agent:coordinator/task:abc/channel:cli"
}

​
Decay classes

ClassHalf-lifeBehaviorExamples
permanentNeverConfidence never decreasesLegal name, date of birth
slow_decay~180 daysHalves every 6 monthsEmployer, city of residence
fast_decay~21 daysHalves every 3 weeksCoffee preference, current project focus
Confidence decays using a half-life model: new_confidence = current × 0.5^(days / half_life). See Dreaming for how the decay pass works.

​
Sensitivity levels

Every node has a sensitivity classification assigned at creation time:
LevelDescriptionExport behavior
publicNo restrictionsFreely exportable
internalDefault for most factsExportable with standard authorization
confidentialSensitive business informationRequires elevated authorization
restrictedHighest sensitivityBulk export blocked
Sensitivity is immutable after creation — changing it requires a manual data migration. Skills can provide an explicit sensitivity override when storing facts, or let the system auto-classify using keyword analysis.

​
Node schema

interface KgNode {
  id: string;                          // UUID
  type: NodeType;                      // person, organization, project, etc.
  label: string;                       // display name
  properties: Record<string, unknown>; // arbitrary key-value data
  embedding?: number[];                // VECTOR(1536) for semantic search
  temporal: TemporalMetadata;
  sensitivity: Sensitivity;
}

​
Edge schema

interface KgEdge {
  id: string;                          // UUID
  sourceNodeId: string;                // UUID of the source node
  targetNodeId: string;                // UUID of the target node
  type: EdgeType;                      // works_on, reports_to, etc.
  properties: Record<string, unknown>; // arbitrary key-value data
  temporal: TemporalMetadata;
}

​
Storing facts

When storing a new fact via the memory-store skill: 
interface StoreFactOptions {
  entityNodeId: string;            // the entity this fact is about
  label: string;                   // the fact text
  properties?: Record<string, unknown>;
  confidence?: number;             // default: 0.7
  decayClass?: DecayClass;         // default: "slow_decay"
  source: string;                  // provenance string
  sensitivity?: Sensitivity;       // override auto-classification
  sensitivityCategory?: string;    // hint for auto-classifier
}
A contact’s canonical attributes (title, organization, primary email/phone, timezone, location, pronouns, and similar — see contacts) are not stored as facts. memory-store detects a write that maps to one of these and redirects it to the contact record instead of creating a fact node, so there’s a single source of truth for them. The knowledge graph still holds richer, narrative facts about a person.

​
Validation

Before creating a new fact, the memory validator checks:
CheckOutcome
Deduplication (cosine similarity > 0.92)Updates lastConfirmedAt and merges properties instead of creating a duplicate
Contradiction (conflicting fact exists)Higher confidence wins; lower is archived with previous values preserved
Equal confidence conflictFlagged for CEO review via alert channel
Write rate limit (50 per task)Excess writes dropped with audit log warning

Memory and the knowledge graph

Conceptual overview of the four memory tiers and how they work.

Dreaming

How the decay pass processes temporal metadata overnight.