What Does AEGI Core Verify — and What Does It Not Verify?
AEGI Core is an evidence-assurance layer, not a model validator or business-truth engine. This article explains the boundary in public-safe terms.
QUICK ANSWER
AEGI Core verifies declared evidence conditions. It does not decide business truth.
In public terms, Core checks whether evidence is sufficiently bound to the declared identity, scope, version and integrity conditions for review. It can help determine whether the evidence state is reviewable within that boundary.
Core does not prove that a customer outcome was correct, certify legal compliance, validate model performance, certify fairness, close audit or authorise production change.
WHY A SEPARATE EVIDENCE LAYER EXISTS
AI and risk workflows generate many kinds of output: scores, recommendations, routes, labels, policy results and reviewer actions. Later, a risk, audit or engineering team may need to understand what actually happened.
The problem is that an output can remain visually plausible even after the evidence around it becomes incomplete or detached from its evaluated state.
Questions appear:
- Which version produced this result?
- Which scope applied?
- Was the expected evidence present?
- Was the evidence altered after generation?
- Does the record belong to the declared evaluation state?
- Can the reviewer distinguish insufficient evidence from a negative business outcome?
AEGI Core exists to make those questions machine-checkable within a declared verification boundary.
CORE VERIFIES EVIDENCE, NOT THE WORLD
This distinction is central.
A fraud-labelled application in a dataset is a business label. A credit outcome is a business decision. A model score is a model output. A policy decision is an institutional action.
Core does not transform any of those into universal truth.
Instead, Core asks whether the declared evidence satisfies the conditions required by the applicable verification profile and scope.
WHAT “DECLARED EVIDENCE CONDITIONS” MEANS
Publicly, the concept can be understood through four questions:
Identity. Is this the evidence object, workflow state or release identity that the verifier expects?
Scope. Is the evidence being interpreted inside the scope for which it was produced?
Version. Are the relevant versions and bindings consistent with the declared verification state?
Integrity. Is the evidence intact enough for the verifier to rely on it within the stated boundary?
The exact internal canonicalisation, binding and test-vector mechanics are implementation details and are intentionally not published in this article.
WHY “INVALID” IS NOT THE SAME AS “BAD BUSINESS DECISION”
An evidence-verification result and a business judgement answer different questions.
If evidence is invalid under a declared verification rule, that means the evidence package does not satisfy the rule. It does not automatically mean the customer was low risk, the model was inaccurate or the underlying business action should have been different.
Likewise, an evidence package can be structurally valid while the underlying model still performs poorly. Evidence integrity does not imply model quality.
WHY “UNDETERMINED” CAN BE A USEFUL RESULT
In many control systems, missing evidence is silently treated as absence of a problem. AEGI takes a different position.
If required evidence is insufficient for a verification conclusion, the correct state can be UNDETERMINED rather than forcing a false positive or false negative conclusion.
This is useful because it separates “the evidence does not support a conclusion” from “the conclusion is negative.”
CORE VS MODEL VALIDATION
Model validation can test conceptual soundness, data quality, performance, stability, implementation, fairness, calibration and other institution-specific requirements.
Core does not replace that work.
A model can pass formal validation while one exported evidence package is incomplete. Conversely, a package can pass evidence verification while the model still requires validation, monitoring or remediation.
The two control functions can complement each other because they operate at different layers.
CORE VS AUDIT
Audit interprets evidence in a broader governance and control context. Core can provide a machine-verifiable evidence state, but it does not close audit findings or replace auditor judgement.
A useful formulation is:
AEGI Core provides evidence assurance for interpretation; it does not own the interpretation.
CORE VS COMPLIANCE
Core does not certify that an organisation, workflow or decision complies with law or regulation.
Regulatory and legal requirements depend on jurisdiction, institution, product, customer, deployment mode and other facts outside the verifier’s evidence boundary.
Public AEGI materials therefore use terms such as reviewability, evidence assurance and scope-bound verification rather than “compliance certification”.
WHY CORE MATTERS TO AEGI SHIELD
AEGI Shield evaluates and governs AI-assisted workflow change. Core provides a separate assurance layer for the evidence generated around that process.
The separation is deliberate:
Shield coordinates risk context and controlled change. Bank policy controls action. Core verifies declared evidence.
This makes it harder for a later reviewer to confuse an AI recommendation, a policy decision, an evidence-verification state and a business outcome.
AN EXAMPLE
Suppose a historical replay compares a current fraud-review baseline with a proposed Shared-Context treatment.
The business question is whether the treatment creates decision-relevant value under the declared review constraint.
The Core question is different: does the evidence package correspond to the declared run identity, scope and version state, and is it sufficiently intact for review?
One result cannot substitute for the other.
WHAT CORE DOES NOT CLAIM
- It does not prove fraud.
- It does not prove creditworthiness.
- It does not prove a model is accurate.
- It does not certify fairness.
- It does not certify regulatory compliance.
- It does not replace independent model validation.
- It does not grant customer-action authority.
- It does not grant production-change authority.
FREQUENTLY ASKED QUESTIONS
Is Core a blockchain?
No public AEGI claim depends on describing Core as a blockchain. Core is defined by its evidence-verification role, not by a marketing label for one implementation technology.
Does Core need to replay the AI model?
The public evidence-assurance concept is designed so verification can operate on declared evidence rather than treating full model replay as the only possible verification method.
Can Core tell whether the workflow should go to production?
No. That remains an institutional decision using business, technical, risk, security and governance evidence.
NEXT STEP
For AEGI Shield, evidence assurance becomes most useful when one bounded workflow and one proposed change have been defined clearly enough that reviewers know what evidence should exist.
CLAIM BOUNDARY
This article intentionally stays at the public evidence-assurance layer. It does not disclose byte-level canonicalisation rules, internal schemas, sensitive conformance vectors, failure edge cases, cryptographic binding implementation or patent-sensitive protocol details.