Developers
Choose how you want to work with Records.
Start locally, embed the engine, or connect an automated workflow. Each surface has one job and an explicit boundary.
Start locally. Add shared context only when the workflow needs it.
Each entry point declares its validator and runtime boundary; Records adds history, comparison, investigation, and evidence.
Integration surfaces
Different entry points, one validation contract.
Start in the surface closest to the workflow. Move into Records when a one-off result needs history, comparison, investigation, or evidence.
CLI
Local files and CI gates.
Engine
Embedded TypeScript runtime.
Agent tools
Claude Code or Codex local work.
MCP
Tenant-scoped run context.
Deterministic validator
Explicit release, packages, terminology, rules, and output
Local decision
Exit code, JSON, SARIF, or JUnit output.
Records context
Runs, baselines, comparisons, and evidence.
Developer surfaces
Available · Apache-2.0
Records CLI
Run local FHIR checks and CI gates, then connect to Records for baselines and evidence.
Available · Apache-2.0
Validation engine
Embed the TypeScript validator directly in a Node.js service.
Available · MIT
Records Agent Tools
Add local validation guardrails to Claude Code or Codex.
Records deployment
MCP server
Expose tenant-scoped validation and run context to compatible agents.
Reference
Compatibility
Check public API support, tested lanes, package coverage, and preview boundaries.
One explicit validation boundary across every surface.
The integration changes. The measurement boundary should not.
Explicit inputs
FHIR release, profiles, terminology, rules, and runtime context stay visible.
Signals, not authority
The tools report findings and status. Your application or governance owns the action.
Bounded access
Local tools stay local; connected tools receive only the tenant and deployment scope they require.
A path into Records
Add run history, baselines, comparison, and evidence when a one-off validation is no longer enough.