Skip to case-study content
KAJEESAN

SANITIZED SYSTEM CASE

OpenHealthAtlas

From scattered records to traceable evidence, and from hidden relationships to the next question worth testing.

OpenHealthAtlas prepares comparable evidence by normalizing records into canonical entities with explicit provenance, time, and context—so signals from different systems can be aligned and trusted.

External Hermes then investigates within defined bounds, surfaces patterns and explanations, and formulates the next useful question for people to test, decide, and replay.

MY ROLE
PRODUCT DIRECTION / SYSTEMS ARCHITECTURE / IMPLEMENTATION
Quick tag
Open the fictional UI demoGitHub
Follow the evidence path

TRANSFERABLE ARCHITECTURE

Why this architecture transfers.

The health example makes the structure visible; the implementation logic applies wherever consequential decisions depend on fragmented records.

Most organizations operate with records spread across systems, inconsistent states, and relationships that are difficult to inspect together. The architecture turns that fragmentation into a repeatable capability: canonical evidence, bounded investigation, human judgment, and a replayable outcome.

Implementation begins by mapping the decision, defining canonical entities and time semantics, and registering deterministic operations. The domain changes. The evidence-first architecture remains.

The source systems change; the governed evidence handoff remains.Illustrative transferable architecture

PROBLEM

The problem was not a lack of AI.

Data existed, but incompatible identities, units, timestamps, and states made dependable comparison difficult.

Training, recovery, nutrition, symptoms, laboratory values, and observations arrived in different shapes. Placing them on one screen would not make them comparable, time-aware, or trustworthy.

The expanded Training record shows the real work hidden beneath a category label: sessions, exercises, load, context, and provenance each need an explicit place before a downstream system can interpret them together.

Six record domains, each carrying different identities, units, times, states, and provenance.Sanitized fictional input model

CANONICAL MODEL

Preserve meaning before calculation.

Every normalized observation keeps its identity, measurement, time, and provenance intact.

I defined a canonical record contract that preserves source identity, units, observation state, and the difference between event time, effective time, and provenance time.

That structure prevents silent conversions and unstated assumptions. If a mapping or definition changes, affected evidence can be traced and rebuilt instead of persisting as an uninspectable summary.

Authored canonical evidence model

Identity

entity_typeentity_idsource_systemexternal_idstateversion

Measurement

kindvalue_numericvalue_textunitmethodnormal_range

Temporal

observed_atrecorded_ateffective_atperiod_startperiod_endtimezone

Provenance

collected_bydevice_idsource_systemingested_attransformationconfidence
Validated factEvidence IDRegistered method ready
The canonical contract preserves meaning before a registered method can use the evidence.Representative repository-aligned fields

READINESS AND CALCULATION

Deterministic by design.

Registered methods establish what can be calculated, and failure states explain when the evidence cannot support the request.

OpenHealthAtlas validates the bounded request, checks comparable coverage, runs a registered method, and returns the limitations with the result. The same evidence and method produce the same calculation.

Insufficient data is a useful outcome because it identifies the next evidence gap. Unsupported and refused requests remain explicit instead of degrading into best-effort prose.

Registered method flow

  1. Validate requestCheck inputs, entities, method, and bounds.
  2. Check readinessAssess evidence coverage and comparability.
  3. Calculate registered methodExecute fixed rules on canonical evidence.
  4. Attach limitationsReturn assumptions, context, and provenance.
  1. okAll requirements met.
  2. insufficient_dataRequired evidence or context is missing.
  3. unsupportedThe method is not registered in this context.
  4. refusedThe request exceeds declared bounds.

Repeatable means the same evidence follows the same declared method.

Explicit states replace silent assumptions and best-effort answers.Failure-first contract model

AUTHORITY BOUNDARY

One workflow, three authorities.

Deterministic evidence, AI interpretation, and human judgment remain separate while sharing one traceable handoff.

OpenHealthAtlas owns canonical records, validation, readiness, deterministic calculations, provenance, and replay. External Hermes chooses among bounded tools, synthesizes evidence, and proposes candidate hypotheses and explanations.

The human reviewer weighs alternatives, makes the decision, and records the outcome. Every handoff carries the evidence without transferring ownership of the source record.

Evidence to decision

Declared tools + bounds

OpenHealthAtlas

  • Canonical records
  • Validation
  • Readiness
  • Deterministic calculations
  • Provenance and replay

External Hermes

  • Bounded tool choice
  • Follow-up questions
  • Synthesis
  • Candidate hypotheses
  • Explanation

Human reviewer

  • Review evidence
  • Weigh alternatives
  • Decide
  • Record outcome

The system prepares evidence. It does not replace judgment.

Deterministic evidence, external reasoning, and human authority remain distinct.Responsibility boundary

IMPLEMENTATION AND PRIVATE ACCESS

How it runs—private by design.

Source verifies the application stack and access controls; hosting and live network configuration remain owner-supplied.

Stack: Python 3.11+, Flask 3.1.3, Gunicorn 23, SQLite, Jinja HTML, CSS, vanilla JavaScript, and ECharts. The supplied service binds to 127.0.0.1:8100 behind separate TLS.

Source verifies one-hop HTTPS forwarding, passkeys, sessions, secure cookies, CSRF, rate limits, headers, read-only health data, controlled writes, migration checksums, and systemd examples. Oracle, Tailscale, network, and deployment context are not provisioned.

Application controls are verified in source; Oracle Cloud and the actual Tailscale configuration are owner-supplied deployment context.Repository-verified app · owner-supplied hosting context

REPLAY AND AUDIT

Every decision leaves a trace.

The result returns with the request, method version, evidence identities, limitations, and audit steps that produced it.

Replay is not a screenshot of a prior answer. It is the ability to recover the exact evidence set and registered method, run the deterministic step again, and compare what changed.

When a new observation arrives, the next result may strengthen, weaken, reject, or update the evidence. The audit trail keeps that change inspectable without turning an association into a causal or diagnostic claim.

Replayable decision packet

  1. request_idUnique request
  2. method + versionRegistered operation
  3. input evidence IDsBound inputs
  4. resultDeterministic output
  5. limitationsAssumptions + coverage
  6. audit trailImmutable steps
RecomputeCompareVerify
Replay match

Request · method · evidence · result · limitations · audit trail

The path can be recomputed from the same declared evidence and method.Repository-aligned replay contract

MY CONTRIBUTION

What I designed and directed.

I translated an ambiguous information workflow into an inspectable system with explicit authority, contracts, and failure paths.

The transferable competence is not a single model or interface. It is the discipline of deciding what must be deterministic, what AI may investigate, what a person must own, and how every conclusion can be traced back to evidence.

CONTRIBUTIONWorkflow definition
Defined the evidence handoff, stages, inputs, and authority boundaries.
CONTRIBUTIONCanonical record model
Designed the entity, measurement, temporal, and provenance contract.
CONTRIBUTIONFailure-first paths
Modeled insufficiency, unsupported requests, refusal, and alternative outcomes.
CONTRIBUTIONGoverned tool interfaces
Specified bounded operations, inputs, outputs, and limitations.
CONTRIBUTIONProvenance and replay
Kept deterministic lineage and evidence identity attached to every handoff.
CONTRIBUTIONImplementation direction
Directed sequencing, architecture trade-offs, and acceptance criteria.
CONTRIBUTIONEngineering review
Reviewed architecture, data integrity, and implementation behavior.
CONTRIBUTIONPublic explanation
Turned the system into a clear, evidence-bounded case study.