DIEGO CALVIÑO
MenuClose

PRODUCT · AI ENGINEERING · BUILD GOVERNANCE · VALIDATION

E2E Assurance Sandbox

Building software with AI without losing control of requirements, state and evidence.

Generative models can analyse requirements, write code, change tests and review documentation quickly. E2E Assurance Sandbox addresses the harder question: how do we know what was built is actually what was requested?

THE PROBLEM IS NOT THAT AI CAN WRITE CODE

Code can look correct long before it is demonstrably correct.

In a sufficiently complex project, intent, implementation, testing and evidence can lose alignment as the system evolves.

  • A documented requirement that is never implemented
  • Code without a test proving the expected behaviour
  • A passing test that does not prove the requirement
  • Evidence valid only for an older version
  • Documentation that states something different from the code
  • Partial coverage interpreted as completion
  • Later changes that invalidate earlier evidence

FROM A CLAIM TO AN INSPECTABLE CHAIN

A requirement advances only through a linked chain of implementation and evidence.

The final result is not only PASS or FAIL. The system can also make incompleteness, a discrepancy or insufficient evidence visible before an assertion is accepted.

Functional model
  1. Requirement
  2. Implementation
  3. Evidence
  4. Verification
  5. Decision

A public model of the assurance chain. AI can participate in the work, but it does not replace the inspectable link between requirement, implementation and evidence.

WHAT AI ACTUALLY DOES

AI is one of the agents inside the system, not the validation system itself.

It helps interpret requirements, decompose work, propose bounded implementations, adapt tests, analyse results, locate inconsistencies, review documentation and prepare evidence for inspection. There is a deliberate separation between producing an answer and demonstrating that it is correct.

AI DOES NOT DEFINE WHAT “CORRECT” MEANS

The limits of the work are set outside the model.

  1. 01What requirement must be met
  2. 02What scope may be modified
  3. 03What acceptance criteria apply
  4. 04What tests must run
  5. 05What sources have authority
  6. 06What evidence must be retained
  7. 07What conditions allow the next state

NOT EVERY PASS MEANS THE SAME THING

Uncertainty stays visible instead of silently becoming PASS.

Requirement without implementation

Result
It cannot be considered complete.

Implementation without evidence

Result
The implementation is not yet demonstrable.

Partial evidence

Result
Partial coverage remains visible.

Outdated evidence

Result
It must be validated again.

Inconsistent sources

Result
The discrepancy must be resolved before accepting the state.

GOVERN THE BUILD PROCESS TOO

A validated Sandbox baseline used explicit gates rather than trusting that an agent had finished writing code.

  1. 01Work contract
  2. 02Bounded implementation
  3. 03Tests
  4. 04Validation
  5. 05Gate
  6. 06Next state

WHEN EVIDENCE IS ALSO PART OF THE PRODUCT

Traceability is a property of the process, not a document written afterwards.

  • What requirement does this test demonstrate?
  • What implementation is it verifying?
  • Which system version did it run against?
  • What result did it produce?
  • What decision did it allow?

STATE OF DEVELOPMENT

Active development

The Sandbox evolves as a governed engineering product. Validated baselines may be shown as milestones when their evidence is approved; the product itself is not presented as complete.

MY ROLE

Design the system, define its contracts, direct the build and decide what evidence is required for acceptance.

  • Problem and concept — confidence, traceability and validation in AI-assisted software development.
  • Functional architecture — the requirement → implementation → evidence → verification → decision chain.
  • Requirements and contracts — scope, entry conditions, acceptance criteria and execution limits.
  • Build governance — states and gates that prevent progress without the defined conditions.
  • AI-assisted development, testing and final validation — implementation, review, evidence and state reconciliation within those contracts.

STATUS AND MATURITY

Active development

  • Contracts define bounded work
  • Gates prevent unsupported progress
  • Tests contribute evidence
  • Validation compares declared and observed state
  • Reconciliation establishes the next baseline

WHAT E2E ASSURANCE DEMONSTRATES

The interesting question is no longer whether AI can write software. It is how to use systems that produce work quickly without losing control of what they actually built. The answer here is to separate generation from validation, define contracts before execution, keep implementation and evidence connected, make gaps visible and require the final state to be reconstructible from evidence.