Portfolio content wireframeHEADERKajeesan JeevendraIDENTITY · FIRST 10 SECONDS
Design & Innovation Engineer building evidence-led AI systems.
I turn fragmented data and difficult workflows into testable systems designed to save time, reduce risk, or create new value.
I work across problem definition, product development, enterprise implementation, data structure, and applied AI. My role is to make the underlying system understandable, decide what must remain deterministic, and turn the result into something people can test and use.
THREE REASONS TO BELIEVE IT
Product development and systems engineering
DTU Design and Innovation trained me to connect user needs, technical mechanisms, organizational constraints, prototyping, testing, and implementation.
Enterprise implementation and data integrity
ERP implementation, SaaS workflows, and CRM migration testing taught me that a system only creates value when its data survives change and people can operate the resulting workflow.
AI and governed data systems
OpenHealthAtlas demonstrates how I structure data, deterministic calculations, evidence, privacy boundaries, AI tool access, and acceptance criteria as one product system.
PORTRAIT
Portrait to be supplied
I am most useful where a problem crosses people, data, technology, and implementation—and where the obvious solution is probably not the real one.
LIVE PROJECT 01
OpenHealthAtlas
Making hidden patterns visible without letting AI invent the evidence.
A local-first system that turns fragmented health records into validated calculations and traceable evidence, then gives external Hermes a controlled foundation for interpretation.
Demonstrates: product architecture · deterministic data processing · provenance · responsible AI boundaries · privacy-aware validation
CONTACT
If the role sits between people, systems, data, and implementation, we should talk.
I am interested in customer-facing AI implementation, deployment, product operations, adoption, and transformation roles.
kajeesan@hotmail.comlinkedin.com/in/kajeesan
SHARED HEADERKajeesan JeevendraCASE OPENING
OpenHealthAtlas
From fragmented health records to evidence an AI can reason over—without becoming the source of truth.
I created and directed the product architecture, evidence model, AI responsibility boundary, validation approach, privacy constraints, acceptance criteria, and user experience through an AI-assisted development process.
Role
Creator and maintainer
Domain
Evidence-sensitive AI and health data
Status
Substantial reference implementation with bounded fictional acceptance
Public proof
Sanitized fictional data only
THE PROBLEM
The data existed. The useful relationships did not.
Training, sleep, recovery, nutrition, mood, symptoms, laboratory results, habits, and goals often live in separate systems. Looking at each source alone hides relationships that may matter only when timing, context, and data quality are considered together.
Simply aggregating the records would not solve the problem. Before an AI can interpret anything, someone has to resolve identity, units, timing, missingness, readiness, provenance, and the difference between association and causation.
The hard problem was not generating an AI answer. It was deciding what the AI should be allowed to treat as evidence.
SIGNATURE EXPLAINER · STATIC CONTENT FIRST
The evidence path
1
Fragmented inputs
Training, recovery, sleep, nutrition, mood, symptoms, labs, habits, and goals arrive with different identities, units, times, and levels of completeness.
2
Validate and standardize
OpenHealthAtlas gives every observation an explicit source, identity, timestamp, unit, and bounded meaning.
3
Build the analysis frame
Registered definitions transform records into a bounded, time-aware frame with visible coverage, transformations, and missingness.
4
Check readiness
The system decides whether the evidence is sufficient. Missing evidence remains insufficient_data; it is never silently converted into a result.
5
Calculate findings
Ordinary software performs deterministic calculations, statistics, bounded associations, stability checks, and interactions. Association is not causation.
6
Preserve evidence
Findings retain sources, time ranges, transformations, fingerprints, ancestry, limitations, and weakening evidence.
7
Hermes investigates
Hermes understands the question, selects tools, combines evidence, ranks plausible explanations, and identifies useful next questions.
8
The user decides
Facts, calculations, AI hypotheses, uncertainty, and source references stay visibly separate and inspectable.
RESPONSIBILITY BOUNDARY
Software establishes what is known. Hermes explores what it might mean.
OpenHealthAtlas owns
Canonical records
Validated reads and writes
Registered definitions
Readiness decisions
Deterministic findings
Evidence identity and provenance
Hermes owns
Conversation
Follow-up questions
Tool selection
Combining evidence
Hypotheses and alternatives
Explanation and next questions
The AI may interpret governed evidence. It does not become the database, calculator, provenance system, and source of truth at the same time.
THREE FICTIONAL PRODUCT VIEWS
Fictional product view
Recovery readiness
Shows which components are eligible, which are missing, and why an overall result cannot be calculated.
Proves:
Missingness, refusal to guess, source consistency.
Shows sources, time ranges, transformations, fingerprints, evidence, and limitations.
Proves:
Traceable findings and inspectable reasoning.
PERSONAL JUDGMENT
My decisions
What I chose
I separated deterministic data work from model reasoning. OpenHealthAtlas establishes records and evidence; Hermes handles conversation and interpretation.
What I corrected
The repository accumulated synthetic interpretation machinery that risked becoming a second reasoning system. I restored the external-Hermes boundary.
What I refused to claim
I do not present associations as causes, hypotheses as diagnoses, fictional evidence as private-data proof, or a reference implementation as a production service.
What I would validate next
One bounded external workflow with a real baseline, measurable result, and independent organizational evaluation.
TRANSFER TO OTHER BUSINESSES
The transferable product is a governed path from fragmented information to an auditable decision.
In OpenHealthAtlas
Health apps, measurements, logs, and notes
Registered health features
Data-readiness gates
Bounded findings and evidence
Hermes interpretation
In another organization
CRM, ERP, support, quality, operational, and spreadsheet data
Shared KPI definitions and rules
Completeness and quality gates
Repeatable patterns and exceptions
An AI operator that selects tools and explains evidence
Potential value to test: less manual assembly, more consistent definitions, faster detection of missing data, more traceable decisions, and new opportunities found in existing organizational information.
DEMONSTRATED
Local-first canonical data
Registered deterministic features
Readiness and insufficient-data behaviour
Statistics, associations, and evidence replay
Evidence identities and provenance
Bounded fictional Hermes tool journeys
Privacy and failure-path validation
NOT YET PROVEN
Clinical validation or diagnosis
Causal health conclusions
Production multi-user operation
Bundled Hermes or model access
Verified customer adoption
Measured revenue or time saving
Every domain and interface end to end
CLOSING
The project demonstrates how I work.
I start with a fragmented problem, define the underlying system, decide what must be deterministic, create the smallest inspectable evidence path, and use AI where interpretation adds value without letting it replace the truth.
If your organization has valuable information trapped across systems, unclear definitions, or AI workflows that are difficult to trust, I would be interested in the problem.