What Data Does AEGI Shield Need? From Public-Safe Scoping to Bank-Controlled Replay
AEGI Shield does not start by asking for a bank's full dataset. This article explains the staged data boundary for one controlled workflow evaluation.
QUICK ANSWER
AEGI Shield does not need customer records for the first conversation. A first discussion can begin with four public-safe elements: the workflow, current baseline, proposed change and decision question.
If the institution chooses to proceed, the bank defines the approved evidence boundary before evaluation execution. That boundary can include the historical cohort, approved signals, baseline identity, outcome labels, review capacity, privacy constraints and material guardrails.
The governing principle is simple: start with scope, not data transfer.
WHY DATA SCOPING COMES BEFORE DATA ACCESS
Many technology evaluations begin with a broad request for data. That can create unnecessary privacy, security, procurement and interpretation risk before the institution has even agreed what question it is trying to answer.
AEGI Shield takes the opposite path. The first task is to define one bounded decision problem.
Examples include:
- Should a new fraud signal be added to the current review workflow?
- Does a challenger treatment create useful value at the same review capacity?
- Does Shared Credit-Fraud Risk Context change the reviewable set?
- Is an AI-assisted recommendation worth taking to a later shadow stage?
Only after the decision question is clear should the institution decide which evidence is necessary.
STAGE 1: FIRST CONVERSATION
No customer records are required.
A useful public-safe outline contains:
- Workflow. What process is being considered?
- Current baseline. What model, rules, ranking, threshold or process currently defines the reference point?
- Proposed change. What exactly might change?
- Decision question. What does the institution need evidence to decide?
This is enough to determine whether a Controlled Workflow Evaluation is even the right next step.
STAGE 2: EVALUATION DESIGN
If the workflow is suitable, the institution defines the evidence boundary.
That can include:
- eligible historical population or cohort;
- approved fields, signals or exported model outputs;
- point-in-time availability rules;
- baseline model or policy identity;
- candidate or treatment identity;
- outcome-label definition and maturity;
- review capacity or another binding operating constraint;
- privacy and security restrictions;
- stop conditions and guardrails.
The objective is not to maximise data volume. It is to make the comparison valid for the decision.
STAGE 3: HISTORICAL REPLAY
Historical replay uses the agreed evidence to reconstruct a bounded comparison between the current baseline and the proposed change.
The comparison should use the same eligible population and material operating constraint for both approaches. If one treatment uses information that was not available at the original decision point, that limitation must be visible.
Historical replay is useful because it can create decision evidence before live customer impact is introduced.
STAGE 4: NON-CUSTOMER-IMPACTING SHADOW, WHERE APPROVED
If historical evidence justifies another step, an institution may choose a separately approved shadow stage.
Shadow testing can observe current inputs and operating behaviour without allowing the candidate to change customer outcomes. It is a different evidence stage from historical replay and requires its own data, security and operating approvals.
AEGI does not treat replay success as automatic permission to move into shadow, or shadow success as automatic permission for production.
DOES AEGI NEED RAW CUSTOMER CONTENT?
Not by default for the public evaluation proposition.
The safer design principle is to use approved, minimised signals and institution-defined evidence rather than collecting raw customer content simply because it exists.
If a workflow genuinely requires more sensitive content, that should be a separately governed exception with explicit scope, purpose, retention and approval controls.
DOES AEGI NEED THE WHOLE BANK DATA LAKE?
No.
A bounded evaluation should identify the minimum evidence needed to answer the declared question. Extra data can increase attack surface, governance burden and the risk of accidental leakage without increasing decision quality.
More data is not automatically better evidence.
DOES AEGI NEED PRODUCTION WRITE ACCESS?
Not for the initial historical replay proposition.
A bounded evaluation can be designed around exported or controlled evidence without granting the candidate authority to mutate production systems. Any later integration path should be separately reviewed and approved.
WHO DEFINES THE DATA BOUNDARY?
The institution.
AEGI can help structure readiness and identify what evidence is necessary for a valid comparison, but the bank retains authority over approved data, privacy constraints, retention expectations and permitted operating modes.
WHAT MAKES HISTORICAL DATA USABLE?
Historical data is not automatically valid simply because it exists.
A useful evaluation should consider:
- whether the data reflects the relevant historical decision point;
- whether labels have matured enough for the declared measure;
- whether the baseline can be reconstructed;
- whether candidate inputs would actually have been available at the time;
- whether missingness or backfilled fields create hindsight leakage;
- whether the evaluation population matches the workflow scope.
If these conditions cannot be established, the correct result may be that the workflow is not ready for evaluation yet.
HOW THIS REDUCES ENTRY FRICTION
The staged data model separates three questions that are often mixed together:
Can we describe the problem? Public-safe scoping.
Can we evaluate it? Bank-approved historical evidence.
Should we integrate it? A later decision based on the evaluation result.
This allows an institution to learn before taking on the cost and risk of production integration.
FREQUENTLY ASKED QUESTIONS
Can AEGI start with synthetic data?
Synthetic or public data can exercise mechanisms and evaluation discipline, but it cannot establish institution-specific business value. That requires an appropriate bank-controlled evidence stage.
Can data stay institution-controlled?
The target operating model is defined by the institution and deployment scope. Public AEGI materials do not claim a universal data architecture for every customer deployment.
What if the bank cannot reconstruct the baseline?
That is a material limitation. A weakly reconstructed baseline can make the comparison misleading.
What if labels are immature?
The evaluation can be delayed, reframed around a different outcome or explicitly report insufficient evidence rather than forcing a conclusion.
NEXT STEP
Do not start with a data upload. Start with the workflow and the decision you need to make.
CLAIM BOUNDARY
This article explains AEGI Shield’s public data-scoping model. It does not publish customer schemas, partner-specific mappings, internal feature definitions, sensitive field-level logic, retention configurations or production deployment architecture.