Skip to main content

Technology

Autonomy is an architecture, not a feature you switch on

Four things have to be true before a transformation system can be left to run: it must decide what to do from the state of the estate, it must get more certain over time without getting more permissive, it must be able to prove a run is correct, and it must know which decisions are not its to take.

The shape of a run

Every run follows the same five stages

The loop is fixed. What changes between engagements is the contents of each stage: which sources are planned, which rules execute, which assertions must pass, and where the gate is set.

The control loopRepeats per run
  1. 01

    Plan

    Read source state and lineage, then build the run plan for what has actually changed.

  2. 02

    Execute

    Ingest, map and transform inside the action space the design permits.

  3. 03

    Validate

    Assert, reconcile and measure drift across the full population.

  4. 04

    Decide

    Publish, publish in part, hold or roll back at the release gate.

  5. 05

    Learn

    Record outcomes and review decisions, then move thresholds within their bounds.

After Learn, the loop returns to Plan. Nothing in the cycle can skip Validate, and nothing that fails Validate can reach Publish, regardless of how confident the system is.

The autonomy approach

Four mechanisms, and the limits designed into each

Autonomy that cannot be bounded is not something a regulated business can adopt. Each mechanism below is paired with the constraint that makes it safe to run unattended.

Approach 01

Orchestration

A planner, not a schedule

A scheduler runs jobs at a time. An orchestrator decides what should run, in what order, given what has actually changed. The system builds each run plan from the state of the estate: what arrived, what drifted, what failed last time and still needs reprocessing, and what downstream models depend on it. Dependencies come from lineage rather than from a hand-maintained graph, so adding a source does not depend on someone remembering to update the schedule.

  • Run plans derived from source state and lineage rather than from a fixed calendar.
  • Backfill, retry and partial reprocessing are normal operations, not incidents.
  • Concurrency and resource limits are enforced per source, so one estate event cannot starve the rest.
  • Every plan is stored with the inputs that produced it, so any run can be explained afterwards.
Approach 02

Learning and adaptation

Confidence moves, authority does not

The system proposes mappings and repairs, scores each proposal on the evidence behind it, and records what happened when a reviewer accepted or rejected it. Those outcomes move the confidence thresholds for that source and that class of change. The adaptation is deliberately narrow: it changes how certain the system must be before it acts, never what it is permitted to do. The set of permitted actions is fixed in the design and changes only when a person changes it.

  • Mapping proposals scored on structural, statistical and semantic evidence, field by field.
  • Review outcomes fed back as labelled examples for that estate, never pooled across clients.
  • Thresholds move inside bounds agreed at design time; the action space itself stays fixed.
  • Nothing is learned from data the system was not explicitly granted for that purpose.
Approach 03

Validation

The gate that decides whether a run is real

Validation runs on the full population, before publication, and it is the only thing that can promote a run. Assertions cover structure, referential integrity, business rules and distribution. Reconciliation compares against source, or against the outgoing platform where one still exists. The gate returns one of four outcomes, and no confidence score can override it: publish, publish in part, hold, or roll back.

  • Full-population checks rather than sampling, with thresholds set per rule.
  • Reconciliation against source or legacy platform, with differences explained rather than counted.
  • Distribution drift measured against an agreed baseline, not merely against the previous run.
  • A run that fails its own checks cannot be published by the system under any circumstances.
Approach 04

Human in the loop

The decisions a system may not take

Autonomy without an escalation path is just an unattended failure. Every system we build names in advance the decisions it is not permitted to take: rules with material financial impact, ambiguous entity matches above an agreed threshold, structural changes to the target model, anything touching classified fields. Those arrive in a review queue carrying the evidence, the proposed action and the consequence of each option. The queue is part of the system, not an inbox beside it.

  • An escalation policy written and agreed before the build rather than discovered in production.
  • Each item carries its evidence, the proposed action and the effect of accepting or rejecting it.
  • Decisions are attributable and timestamped, and become part of the permanent audit trail.
  • Authority can be delegated per source as confidence is established, and withdrawn the same way.

Architecture

The reference architecture every engagement starts from

This is the skeleton. The connectors, the rules, the assertions and the thresholds are all specific to your estate, but the order of the layers and the position of the release gate do not move.

  1. Layer 015 components

    Sources

    Whatever the estate already has, connected read-only until a design says otherwise.

    • Relational databases
    • Cloud warehouses
    • Object storage and file drops
    • Event streams
    • Business applications and APIs
  2. Layer 024 components

    Ingestion and capture

    Every pull captures the schema it saw, so drift is a detected event rather than a downstream surprise.

    • Connector runtime
    • Schema capture
    • Change detection
    • Landing zone
  3. Layer 035 components

    Autonomy core

    Where profiling, mapping, rules and policy meet to produce a run plan and execute it.

    • Profiler
    • Mapping engine
    • Rule engine
    • Planner and scheduler
    • Confidence and policy
  4. Layer 045 components

    Validation and control

    The gate. Nothing reaches publication without passing it, and nothing passes it silently.

    • Assertion suite
    • Reconciliation
    • Drift detection
    • Quarantine
    • Release gate
  5. Layer 054 components

    Publication

    Conformed, validated, documented data in the places your teams already consume it.

    • Conformed model
    • Warehouse and lakehouse targets
    • Serving APIs
    • Downstream analytics
Cross-cutting spine

These are not a sixth layer. Each one applies to every layer above it, and each is written into the system rather than bolted on before an audit.

  • Lineage

    Source column through to published field, generated from the run rather than drawn afterwards.

  • Immutable audit log

    Every run, decision and rule change with its inputs, evidence and author.

  • Access control

    Role-based, scoped per stage and per classification, revocable without redeployment.

  • Observability

    Freshness, volume, drift and failure rates per source, routed to the owning team.

  • Human review queue

    The escalation path, held inside the system so decisions stay attributable.

Reference architecture, read top to bottom: data enters at the source layer, is captured with its schema, is planned and transformed in the autonomy core, must clear the release gate in validation, and only then reaches publication. The spine on the right applies across every layer. What changes per engagement is the contents of each layer, never the order of the gates.

Want this walked through against your own estate?

A technical session goes through the architecture with your engineers, using your sources and your constraints, and ends with an honest answer about which parts could run unattended and which could not.