Leida Core

    Compliance central brain
    that connects every moving part

    Core is the impact engine for regulated product development. It connects intent, requirements, risk, verification and records into one evidence chain, then uses AI to draft new documentation or update existing documentation when the product changes.

    What Core does when the
    product changes

    When a requirement is updated, a ticket closes, a pull request merges, or a test result changes, Core traces what is affected and creates a clear list of updates. It then drafts the document edits and structured record changes so the team reviews concrete proposals instead of chasing gaps.

    What Core does when the team
    needs new documentation

    Core generates all the needed regulated documentation in the team's format and terminology, then link it to the evidence chain. This keeps new work connected to requirements, risks, controls, and verification from the start, instead of being written in isolation.

    Core actions

    • Define product intent before code: intended use, user groups, markets, high-level features, data types
    • Create documentation and assign tasks
    • Ask questions and explore: "what is the safest way to ship this?", "What does this imply for EU MDR and FDA QSR pathways?", "What features trigger extra burden?", "What is the minimum compliance path?"
    • Run impact analysis on planned or actual changes: "What does this change affect and why?"
    • Generate drafts and deltas: redlines, rationales, training deltas, evidence checklists
    • Simulate options: different release scopes, market rollouts, feature-flag on/off, architecture alternatives
    • Inspect provenance: see what sources and versions the reasoning used

    Inputs

    • Design intent: intended use, claims, user groups, markets, data flows, architecture options
    • Engineering signals: commits, branches, tags, diffs, dependency updates, config changes, feature flags, CI results
    • Process context: SOPs, internal thresholds, acceptance criteria
    • Controlled knowledge: approved requirements, risks, tests, records from QMS or external eQMS
    • Regulatory corpus: standards mappings, guidance references, internal interpretation library

    Outputs

    • Structured proposals and ready documents
    • Full audit trail and assigned tasks
    • Impact map: affected requirements, risks, tests, controls, docs
    • Rationale: why each item is impacted, grounded in trace links and provenance
    • Evidence checklist: what must be done and what proves it
    • Draft artifacts: redlines, release rationale, training scripts, release notes, change classification suggestions
    • Options: recommended courses of action with tradeoffs and assumptions

    Inputs

    Pull change signals and existing evidence from the tools already in use.

    Ingest requirements and tickets, code changes and releases, test results, and current documentation so the evidence chain stays grounded in real work.

    Core Reasoning

    Build a living map of the device program, then follow the ripple effect of change through requirements, risks, controls, verification, and records.

    Turn that impact into a clear set of proposed updates and evidence needs.

    • Draft documents
    • Edit documents
    • Create impact map
    • Trace updates
    • Create evidence checklist

    Outputs

    Build a living map of the device program

    Connect what the product is meant to do to what was built, what could go wrong, how it is controlled, and how it was tested so it stays clear what proves what.

    Do the detective work when things change

    Track a change as it moves through the system and show exactly which requirements, risks, tests, and documents it touches, then produce a clear list of what to update next.

    Create and update regulated documentation with AI

    Write the first draft of documentation and keep it current as the product evolves, producing ready-to-review edits instead of starting from a blank page.

    Build a living map of the device program

    Build a living map of the device program

    Connect what your product is meant to do to what was actually built, what could go wrong, how it is controlled, and how it was tested. Keep the full chain in one place so it is always obvious what actions proves which evidence.

    Do the detective work when things change

    Do the detective work when things change

    Track a change as it travels through the system and show exactly which requirements, risks, tests, and documents it touches. Turn "we should probably update something" into a clear, specific list of what to update next.

    Create and update regulated documentation

    Create and update regulated documentation

    Write your device documentation with AI and keep it current as the product evolves. Produce concrete edits and ready-to-review text so the team improves and approves, instead of starting from a blank page every time.

    Problem it addresses

    SaMD development produces continuous change. Regulation and quality demand traceable, defensible decisions. Today, impact is discovered late and reconstructed manually. QA becomes a bottleneck or a cleanup crew. Engineering ships with uncertainty. Compliance becomes a static document exercise in a continuous software world.

    Why this exists

    Core exists to compute regulatory meaning from change and from planned design intent, without touching controlled records. It converts scattered inputs into structured intent: impact, rationale, evidence needs, and decision options.

    How the problem is solved in practice

    Core continuously ingests signals from design planning, engineering work, and existing controlled artifacts, then produces a compliance delta and a proposed action package. It does not commit anything. It produces proposals that can be reviewed in staging.

    What it makes easier, simpler, faster
    • Seeing regulatory impact immediately after code or config changes
    • Understanding why something matters, not just that it changed
    • Comparing alternative release paths before committing
    • Drafting regulatory rationale in minutes instead of days
    Main users

    QA/RA leads, product leads, CTO/engineering leads, system architects.