I
Impetora
Methodology

TRACE

Trust, Readiness, Architecture, Citations and Evidence. The four-pillar methodology Impetora uses to ship AI systems that hold up in regulated work.

T
Trust pillar - data residency, audit trails, risk classification
R
Readiness pillar - written brief before any code is written
A
Architecture pillar - production systems, never POCs
C
Citations pillar - every output traceable to its source
High-risk AI systems should be designed and developed in such a way that natural persons can oversee their functioning, ensure that they are used as intended and that their impacts are addressed over the system's lifecycle.
EU AI Act, Recital 73 (Regulation 2024/1689)
The four pillars

What TRACE actually means.

Each pillar is a discipline we apply to every engagement. None are optional. None are bolt-on.

Pillar T

Trust

T

Data residency, append-only audit logs, EU AI Act risk classification before architecture begins, and ISO 42001-aligned governance. Trust is built into the stack, not bolted on.
Pillar R

Readiness

R

No code is written until the data, the workflow, and the success metric are in writing. The readiness brief is the contract. If the brief cannot be written, the project does not start.
Pillar A

Architecture

A

Specification-driven development. Versioned prompts with eval suites, shadow-mode rollouts, plain-language runbooks. We refuse architectures we cannot audit end to end.
Pillar C

Citations and evidence

C

Every output links to the source document, the prompt version, and the model run. A reviewer signing off on an exception can trace any decision to its cause in under 10 seconds.
The pipeline

From discovery to operate.

Three phases, gated by written deliverables. You sign each gate before the next phase begins.

DiscoveryReadiness briefBuildSpec + eval suiteOperateRunbooks + audit
The TRACE pipeline. Each stage produces an artefact you sign before the next begins.
The delivery model

Discovery, Build, Operate.

Three phases, each gated by a written deliverable. You sign the brief before code is written. You sign the rollout plan before production. You own the runbooks before we step back.

  1. 011 to 6 weeks

    Discovery

    An embedded readiness sprint. We shadow the workflow, sample 30 days of real data, baseline the metrics, and write the spec. You sign the brief before code is written.

  2. 024 to 12 weeks

    Build

    Specification-driven development with automated evaluation. Phased rollout from shadow mode to assist mode to autonomous mode, gated by your numbers.

  3. 03Ongoing

    Operate

    Observability, runbooks, and incident response handed to your team. We stay on retainer for evaluation refresh and model-version upgrades.

Methodology FAQ

Frequently asked questions

What does Discovery actually cover?

A workflow audit, baseline of current handle time and error rate from at least 30 days of your real data, scope sign-off with named success metrics, and a written readiness brief that classifies the system against the EU AI Act risk tiers. Output is a signed brief before any production code is written.

Who owns the IP at the end of an engagement?

You. The source code, the prompts, the eval suite, the runbooks, and the architecture diagrams ship to your repository. We do not retain residual IP. We retain the right to describe the engagement at a category level (industry, problem class) for our own reference work, never with client identifiers.

How do you handle change requests during Build?

Every change request goes back to the spec. We update the behaviour spec, the data contract, or the eval suite first, then the implementation. Changes that affect scope are priced and signed before work continues. Changes that affect quality gates require explicit acceptance of the new evaluation target.

What is the typical Discovery output?

A 4 to 8 page brief covering scope, data dictionary, success criteria, baseline numbers from your data, target deltas, ROI model, an explicit out-of-scope list, and a risk classification under the EU AI Act framework. The brief is the artefact you sign before architecture begins.

What happens if Discovery shows the project is not ready?

We say so and refund the unspent retainer. We have killed projects in week three when the data was unfit, the workflow was unstable, or the ROI did not clear. That is the point of Readiness. Saying no early is cheaper than building wrong.

How do you measure success during Build?

Against the baseline numbers captured during Discovery. Every model change runs against the eval suite checked into the repository. Regressions block deploy. We report against the agreed delta weekly through pilot, then at agreed cadence in Operate.

How does shadow mode work?

The AI runs alongside the human reviewer. Output is logged, compared to the human decision, and reviewed at agreed intervals. Nothing the model produces is actioned in production until the agreed-on accuracy and refusal-rate gates clear. Shadow mode is the default for any system touching regulated workflows.

What do you refuse?

Engagements without a written readiness brief, architectures we cannot audit end to end, and any work that asks us to ship without an evaluation suite or an audit log. We also refuse to claim outcomes we have not measured against your data.

Submit a project.

Tell us the workflow. We reply within one business day and scope the discovery sprint before any code is written.

Start a project
Discovery call

Book a discovery call

Tell us what you would like to build. We reply within one business day.

30-minute call. Free of charge. No obligation.