Governed AI
TraceUnified's AI is a governed advisory layer. The agents analyze and propose — they never write to your records. A human applies every change through the normal signed, audited workflow. Advisory by design, license-gated, fail-closed, and fully auditable.
The principle
In a validated environment, the integrity of the requirement, its version history, and the e-signature chain is the whole point. An AI that autonomously edited items would break exactly the thing you are protecting.
So TraceUnified does the opposite. The agents hand a person a recommendation, and the person decides. The compliance record only ever changes by human action, on the audit trail — the same way it does today. Everyone will say they have AI. The difference is AI you can actually turn on inside a Part 11 environment.
Built for cautious buyers
No. The agents produce recommendations. A human reviews and applies every change through the standard workflow — versioned, signed, and audited. AI has no write path to the record.
Yes. Every governance change — enabling AI, switching an agent on, delegating to a project — is written to the Part 11 audit trail with the actor, the action, and the timestamp.
No. You bring your own model-provider key. There is no shared TraceUnified "AI brain" sitting over your tenant data.
Then it cannot be turned on. AI is a licensed, entitlement-gated capability, enforced the moment you enable it and again at runtime.
How it is governed
A brand-new organization has AI fully off at every level. Reaching an agent that can run means clearing a layered chain of controls, every one of which defaults to off.
Your organization must hold an active license that includes AI. No entitlement, no AI — full stop.
A single org-level on/off, off by default. Nothing downstream can run until it is on.
Each agent is individually Off, On, or Delegated. "Delegated" hands the on/off decision down to individual projects.
When an agent is delegated, each project decides for itself — so control can be centralized or distributed deliberately.
Even with everything above enabled, an agent will not run until your own model-provider key is configured. Keys are held as write-only secret references in a managed secrets store (AWS Secrets Manager / KMS) — never in plain application settings.
The agents
In every case the output is a recommendation — a person accepts or rejects it, and even that decision is captured on the audit trail.
Flags ambiguous, weak, or untestable phrasing and missing acceptance criteria.
Proposes a clearer, testable rewrite of an item — for a person to accept or reject.
Surfaces likely-duplicate or overlapping items before they fork your trace model.
Checks an item against a selected regulatory framework and reports what it finds.
OpenAI · Azure OpenAI · Anthropic · your own endpoint
The assistant
Ask it about coverage, suspect links, or the impact of a change, and it answers from your real traceability data — never a guess. It reads the record and proposes; it never writes to it. Governed, fail-closed, on a model you bring.
Coverage, the traceability matrix, suspect links, and the impact of a change — answered from your project, not guessed.
It can propose an artifact — a requirement, test steps, a risk control — as a draft you accept, edit, or reject.
Generate a matrix or coverage report on demand. The assistant reads and proposes; a person makes every change, on the audit trail.
The derivation engine
The assistant reads your model. The derivation engine builds on it. Point it at a set of requirements and it proposes the downstream work products they imply — tests, architecture, risks, an SBOM — each grounded in the sources it came from. Same governed principle: it proposes; you accept; the record only changes by human action.
Decompose high-level requirements into a structured child set.
Propose verification — test cases and a plan — for the requirements that need it.
Propose SysML model elements that realize the requirements.
Surface the actors implied by the requirements.
Propose failure modes as a structured FMEA — you assign the numbers.
Propose a component inventory from the model — you supply versions and hashes.
Proposal only — nothing is written until you accept. Accepting is recorded to the audit trail under your identity.
Every proposed item must cite a real source from your project — an id or display id that actually exists. Items that cite nothing, or cite something unknown, are marked invalid and never quietly kept. The AI cannot invent a source.
A derivation run returns a coverage ledger: which of your source items it could not drive a proposal from, and why. Silence never masquerades as completeness — an honest gap is required, not optional.
It structures an FMEA but will not fill in severity, occurrence, detection, or RPN. It builds a component inventory but will not fabricate versions, hashes, suppliers, or licenses. The AI proposes structure; your engineers own the numbers.
How a run works
A derivation is a pipeline with the human at the end, not the model. Every run ends as a proposal; only your accept turns it into real, traced records.
You choose the recipe and the source items — a set of requirements, a slice of the model.
The engine gathers the real source records and the existing targets, so nothing is derived in a vacuum.
Your model proposes work products, citing the sources behind each one.
Citations are resolved, uncited items rejected, human-only fields stripped, duplicates of existing items suppressed.
The result lands as a proposal in the recommendation ledger — nothing is on the record yet.
In the workbench you accept all, some, or none. Only your accept materializes real, traced records — attributed AI-proposed, human-accepted, on the audit trail.
Questions
Governed, advisory, auditable
TraceUnified's AI is advisory only. It analyzes and recommends; it never writes to your controlled records. Access is gated by license entitlement and a layered, fail-closed control model, and every configuration change is recorded on the audit trail.
yourteam.traceunified.com