What is AEGIS responsible for?

It is the safety and compliance layer. Every request into the platform and every answer out of it passes through AEGIS, which blocks unsafe content, flags unsupported claims and records what happened.

How does it detect a problem?

A combination of policy classifiers, factual-grounding checks against source material, and rule-based filters for regulated categories. Anything above a risk threshold is blocked, redacted or escalated.

Does it slow the system down?

Checks run in parallel with generation and are engineered to add only a small fraction of the total response time, so users experience the platform as a single fast system.

What does it produce for auditors and regulators?

An immutable log of decisions, model versions, data lineage and interventions, mapped to recognised AI-governance frameworks so evidence packs can be produced on request.

Why fund safety as its own module?

In regulated sectors, demonstrable governance is a condition of purchase. Building it as infrastructure rather than an afterthought is what makes enterprise contracts winnable.

All modules

M05 · In Build

AEGIS

Safety, alignment and compliance framework

Investment

$1,500,000

Share of programme

10.5%

Timeline

Q3 2025 — Q2 2027

Delivery team

9 engineers / 4 policy specialists

48% complete

Safety, alignment and compliance shield visualisation for the AEGIS module — M05 · AEGIS — Safety, alignment and compliance framework

In plain English

The control plane and the brakes. It tests every release for harmful, biased or leaky behaviour, enforces policy live, and keeps an audit trail regulators can read.

What the software does

Attacks each new model version deliberately to find the ways it can be made to misbehave, before customers can.
Blocks a release from going live if it fails any of the safety checks that matter.
Filters requests and responses in real time against the customer's own policy rules.
Writes an immutable record of what was asked, what was answered and which controls fired.

How it works, step by step

01Test adversariallyAn automated red team probes each candidate model for jailbreaks, data leakage, bias and unsafe advice.
02Gate the releaseA model that fails a blocking evaluation does not ship. That decision is automatic, not a judgement call.
03Police it in productionLive policy enforcement and continuous monitoring catch drift and misuse after deployment, with every event logged.

A simple analogy

It plays the role of aviation safety certification: nothing takes off without passing the checks, and the flight recorder runs the whole way.

Why it matters

In banking, health and government procurement, demonstrable safety and auditability are the entry ticket — not a differentiator.

How AEGIS works

Inside the module

Every request and every answer passes through here before anyone sees it.

Input

Live traffic
Requests entering and responses leaving the platform
Model releases
Candidate checkpoints awaiting approval
Tenant policy
Per-customer rules and regulatory obligations

M05 pipeline · select a stage

1/4

The incoming request is assessed

Prompts are checked for policy breaches, injection attempts and restricted categories before any compute is spent on them.

Policy classifiersPrompt-injection detectionCategory filters

Output

Safe response
Approved output, or a clear refusal with a reason
Release gate
Pass or fail decision on each model checkpoint
Evidence pack
Audit-ready records mapped to governance frameworks

Stage by stage, in detail

Train-time alignment

Preference and refusal data shape behaviour before a model ever reaches serving.

Automated red-teaming

Every release is probed against jailbreak, exfiltration, bias and hallucination suites.

Release gating

Promotion is blocked automatically when any regression crosses a defined threshold.

Runtime enforcement

A policy engine applies per-tenant rules at inference time, not as a cosmetic output filter.

Evidence generation

Model cards and audit bundles are produced continuously for procurement and regulators.

100%

Gated releases

No model reaches serving without clearing the red-team harness

Frameworks mapped

EU AI Act, NIST AI RMF and ISO/IEC 42001

48%

Module complete

Policy engine live in staging

Adversarial evaluation harnessPer-tenant policy engineInterpretability probesModel card generatorEU AI Act / NIST / ISO 42001 mappings

Questions answered

AEGIS FAQ — how the AI works, in plain terms

Common investor questions about what this module does, how it does it, and why it is funded as part of the programme.

Scope

AEGIS is not a bolt-on filter. It spans training-time preference data, inference-time policy enforcement, and post-hoc evidence generation for auditors.

Continuous automated red-teaming probes each model release against jailbreak, data-exfiltration, bias and hallucination suites, and blocks promotion when a regression crosses threshold.

Jurisdictional policy packs map platform controls to the EU AI Act, NIST AI RMF and ISO/IEC 42001, producing the evidence bundle enterprise procurement teams require.

Contracted deliverables

Automated red-team and adversarial evaluation harness
Inference-time policy engine with per-tenant rules
Audit evidence generator and model cards
Jurisdictional compliance packs

Achieved to date

Red-team harness gating every pilot model release
ISO/IEC 42001 control mapping drafted and internally reviewed
Policy engine enforcing per-tenant rules in staging

Currently in production

EU AI Act evidence bundle automation
Interpretability probes for high-risk decision paths
Third-party assurance audit readiness

Where it is used

Regulated market access

The evidence bundle enterprise procurement and public-sector tenders demand before signature.

Tenant-specific policy

Different customers enforce different rules on the same underlying models.

Incident forensics

Interpretability probes explain what drove a high-risk decision path.

Platform dependencies

Gates every NEXUS and ORACLE release
Enforces tenant isolation inside ATLAS
Constrains HELIX agent permissions

Key risks and mitigations

Regulatory requirements shift

Controls are mapped to frameworks as policy packs that can be revised without code changes.

Over-blocking hurts usability

Policies are measured against utility benchmarks alongside safety benchmarks.