Skip to content

Developer Portal

Use this portal when you are changing the SDK itself, not only running it.

It routes contributors to the architecture, generated API map, subsystem guides, validation commands, and release discipline needed to change behavior safely.

What This Portal Covers

  • architecture and module boundaries
  • exact CLI and integration behavior
  • simulation, safety, data, AI, and edge-device implementation areas
  • contributor workflow, checks, and release discipline
  • the documentation pages that explain each subsystem in depth

Read These First

Need Start Here
See the system visually before editing Visual Architecture
Find every Python module and its public symbols API Reference
Understand the whole SDK architecture Architecture & Module Guide
Check exact CLI behavior and advanced commands CLI & Advanced Reference
Contribute without weakening safety or docs Contribute Safely
Maintain the repository safely Maintainer Guide
See every public documentation surface Documentation Coverage Reference
Prepare a maintained release Maintainer Release Checklist
Need the long-form printable manual Full Technical Manual

Codebase Map

If You Are Changing Main Code Area Read Before Editing
simulation loop, patient state, safety gates src/iints/core/ Architecture & Module Guide
CLI commands and public workflows src/iints/cli/ CLI & Advanced Reference
CGM imports, registries, quality checks, realism src/iints/data/ Data Certification Full Guide, Evidence Base
reporting, posters, study analysis src/iints/analysis/ Scientific Workflow, Study Analysis
local AI preparation and explanation gates src/iints/ai/ AI Assistant
Pi, UNO Q, Jetson, long studies src/iints/live_patient/, src/iints/jetson/ Edge Hardware & SBC Matrix, Jetson Endurance Mode
MDMP packaging split between repos bundled MDMP + CI tools MDMP Packaging Workflow
docs, manuals, public release surfaces docs/, tools/research/ Documentation Coverage Reference, Manual Overview

Before You Change Code

  1. Read the matching subsystem guide from the tables above.
  2. Locate the tests that already describe the behavior you are touching.
  3. Keep the public CLI, generated artifacts, and docs aligned when you change a workflow.
  4. Prefer the smallest relevant check first, then broaden the validation before merge.

Useful commands:

tools/dev/sdk_check.sh quick
tools/dev/sdk_check.sh edge
tools/dev/sdk_check.sh docs
tools/dev/sdk_check.sh full

The generated API Reference is built from src/iints/**/*.py. Regenerate it after public module changes with:

python3 tools/docs/generate_api_reference.py

What Must Stay True

  • algorithms remain separated from deterministic safety supervision
  • simulation runs remain reproducible through recorded configuration, seeds, and manifests
  • data-quality claims stay tied to MDMP validation and cited evidence
  • edge flows keep a clear Linux-side runtime and hardware-bridge boundary
  • public docs, generated manuals, CLI help, tests, and release notes do not drift apart

Change-Type Shortcuts

Add Or Modify A CLI Command

Change Simulator Or Safety Behavior

  • Start with Architecture & Module Guide
  • Inspect tests under tests/core/, tests/validation/, and relevant regression coverage
  • Re-check artifact compatibility before changing outputs

Change Data Or Realism Logic

Change Edge Hardware Support

  • Start with Edge Hardware & SBC Matrix
  • Read the board-specific guide before changing user-facing flows
  • Run tools/dev/sdk_check.sh edge

Prepare A Release

Definition Of Done

Before a code change is considered complete:

  • the implementation is updated
  • relevant tests are added or adjusted
  • user-facing docs are updated if the workflow changed
  • flake8, mypy, and the relevant pytest slice pass
  • generated docs still build cleanly
  • release-facing files are updated when public behavior changed

If you are unsure where to begin, use Documentation By Role or Choose Your Path to route yourself to the right level of detail.