AKHANDA working name

01 · Rationale

Why this exists

What changes when it exists

02 · Position

Position in the architecture

AKHANDA is not a database wrapper and not an EMR. AAROGYA holds the EMR. AKHANDA holds the clinical interpretation of the patient — the reasoned state, not the record of encounters.

03 · Core model

Core model

The five node families

Edge semantics

Edges carry semantics, not just linkage:

The Belief node — the hard part

Beliefs are what make AKHANDA a clinical graph rather than a data lake. A Belief is a defeasible assertion by a named agent at a named time with a named basis.

belief:
  asserted_by: hridaya@v10.2      # product + version, never "the system"
  asserted_at: 2026-08-09T11:04:22Z
  statement_type: risk_score | differential | trajectory | contraindication
  basis:
    observations: [obs_..., obs_...]
    kb_refs: [HRIDAYA_KB14@1.2]
  confidence: 0.0–1.0
  claim_grade: established
  supersedes: <prior belief or null>

• Beliefs are never deleted, only superseded or retracted. The graph is append-only.
• Two products may hold contradicting beliefs simultaneously. AKHANDA does not resolve them; it exposes the contradiction via a contradicts edge and lets the consuming product or clinician arbitrate.
• A belief with no basis is rejected at write time. Unattributable assertions do not enter the graph.

Temporal semantics

Bitemporal. Every node carries valid time (when it was true of the patient) and transaction time (when the system learned it). This is what makes "what did we know at 14:20 when the decision was made?" answerable — which PRAMANA requires for fair outcome attribution, and which medico-legal defence requires absolutely.

04 · Knowledge

The KB library — 84 KBs

Six layers, authored and clinically reviewed before the engine that consumes them. Every KB carries a claim grade that governs downstream hedging language.

Full KB manifest — grades, dependencies & scope →

05 · Data

Data architecture

Every assertion records: node family, payload, asserting product + version, valid time, transaction time, basis (observations + KB references — must be non-empty), confidence, claim grade, supersession chain, and trace id.

The snapshot API — the primary read surface

Consumers rarely traverse the graph directly; they request a composed state snapshot at a point in time:

GET /v1/patient/{id}/snapshot?as_of=<ISO8601>&lens=<product>

lens shapes the projection — HRIDAYA gets a cardiac-weighted view, SAATHI gets a patient-safe view with claim grades translated to plain language.

06 · Engine

Engine components

07 · Proof

Acceptance criteria

• Append-only enforced at the database level; UPDATE/DELETE attempts fail and alarm
• Graph projection fully rebuildable from the ledger with byte-identical results
• Bitemporal query returns correct state for any past instant, proven against a 50-case fixture set
• Write with empty basis rejected 100% of attempts
• Contradiction between two products surfaced, never silently resolved
• Consent revocation propagates to all downstream subscribers within 60 seconds
• Break-glass access logs immutably and notifies within 5 minutes
• Snapshot p99 latency < 400 ms at 10,000 patients
• Zero PHI in logs (automated scan in CI)

08 · Failure

Degraded mode

Degraded mode is defined, not emergent. Default is fail-safe: reduce function, never guess.