Model or supplier
A new model, provider, fine-tune, retrieval layer or system prompt may invalidate earlier testing and supplier assurance.
DELTA · AI change control
DELTA compares the AI or automated system you approved with the version you now plan to release. It shows what changed, what still stands and what you need to reopen before deployment.
DELTADeployment Evolution and Legal Trigger Assessment
One baseline. One proposed release. One reasoned route.
Release notes say what changed.
DELTA says what follows.
Keep what still stands.
Reopen what no longer does.
The problem
A release ticket records the engineering change. It rarely tells legal, compliance, risk or audit teams whether the organisation can still rely on the original approval.
A model update may alter capability. A new data source may alter inference. A new tool connection may give the system power to act. A change in purpose may move the system into a different legal or governance category.
The question is not only “What changed?” It is “What does the change disturb?”
A new model, provider, fine-tune, retrieval layer or system prompt may invalidate earlier testing and supplier assurance.
New inputs, derived attributes or monitoring data may alter privacy, fairness, security and transparency analysis.
A system approved for support may now rank, select, reject, price or act for a new population or market.
New permissions, APIs, credentials or action channels may turn a recommender into an operational decision-maker.
What it is · what it is not
DELTA is
DELTA is not
DELTA does not redo everything. It tells you what to reopen.
How it works
DELTA follows the change from a factual comparison to an authorised route. Each stage uses the same colour language as the TRACE product family.
Fix the approved baseline, proposed release, decision owner, scope and date.
Describe the factual changes to purpose, people, data, model, architecture, autonomy, actors and controls.
Identify the assumptions, approvals, assessments, tests and notices that the change touches.
Check evidence, validation, oversight, supplier assurance, transparency, rollback and unresolved gaps.
Record the route, reasons, conditions, owners and events that will require another review.
The result
DELTA gives the organisation a provisional route and explains why.
Keep the change history. The recorded facts do not trigger further work.
Correct records, notices or technical descriptions before release.
Review defined modules while preserving unaffected evidence.
Rebuild the approval basis because a foundational assumption no longer holds.
Resolve a blocking issue and obtain authority before release.
Outputs
DELTA creates a small set of usable records rather than a generic compliance dashboard.
Change Record — the approved baseline, proposed release and material differences.
Reassessment Map — the approvals, assessments, controls and evidence that the change affects.
Release Route — the outcome, reasons, unresolved gaps and conditions.
Action Register — owners, deadlines, evidence needs and future review triggers.
Who it is for
Engineering knows what changed. Governance teams must decide what follows. DELTA gives both sides one structured comparison and one common record.
The decision owner remains accountable. DELTA structures the work; it does not assume authority.
The technicals
DELTA runs as a deterministic browser application. It compares one approved baseline with one proposed release, tests the recorded facts across defined trigger domains and applies a transparent outcome hierarchy. The core result does not depend on generative AI.
Access and licensing
Explore a complete fictional change and see how DELTA reaches its result.
Use DELTA for one named system and one defined change event.
Put DELTA into the internal release process for one named legal entity.
A narrow promise
DELTA produces structured decision support. It does not certify compliance, replace professional judgement or bind a regulator, court, auditor or notified body. The result remains conditional on the facts, evidence, law and rule pack recorded at the assessment date.
Read the product boundaryStart with one real change
Use the public example first. For a pilot or licence, identify the system, approved version, proposed version and decision timetable.