Skip to main content
Keller AIRequest a demo

ARCHANGEL · SOFTWARE ARCHITECTURE GOVERNANCE

Keep the Why.

Turn business intent into architecture
your team can build.

Built for product, architecture, and engineering teams in regulated enterprises. Archangel helps explore designs, checks them against defined rules, and keeps requirements, decisions, and evidence connected.

Request a demo Explore Archangel
01 /
Decision Trace, in motion.

Modernizing sign-in for a sample mainframe credit-card application.

The example: CardDemo, an open-source sample mainframe credit-card application. The goal: move sign-in to the cloud while preserving access for existing users and administrators.

HOW ARCHANGEL CHECKS AI

AI reasoning.
Deterministic
verification.

AI helps interpret your goals and explore options. Deterministic verification checks the design against defined rules, with results you can inspect.

The design must meet the rules set for it. A convincing explanation is not enough.

Inside the technology
  1. 01

    DEFINE THE RULES

    Make the requirements clear.

    Turn policies and business needs into clear rules the design must meet. Keep each rule linked to where it came from.

    Example ruleNever store passwords as readable text.
  2. 02

    CHECK THE DESIGN

    Check AI-generated designs against the rules.

    Archangel uses deterministic verification to check whether a proposed design satisfies the rules encoded for it. The findings stay connected to the decision.

  3. 03

    DECISION TRACE

    Keep the why with what comes next.

    See what was chosen, why it was chosen, and which requirements shaped it. Keep that reasoning with the engineering work so teams can understand the impact of a change.

FROM INTENT TO ENGINEERING

An initiative becomes
a plan your team can use.

The requirements, design choices, and engineering plan stay connected, so the reasoning carries through to the build.

EXAMPLE / MAINFRAME MODERNIZATION

Modernize sign-in. Preserve existing access.

CardDemo is a sample credit-card application running on a mainframe. This project moves sign-in to the cloud while keeping existing access working for users and administrators.

01

Clear requirements

REQUIREMENTS

Upgrade sign-in.
Keep access working.

01

Keep users and administrators able to reach the right parts of the application.

02

Connect the existing sign-in to a cloud identity service.

03

Keep passwords and other secrets out of the code and settings.

Requirements grounded in context

Make the goal, requirements, and open questions clear.

02

Connected architecture

DESIGN APPROACH

A bridge today.
A new interface next.

PHASE 01

Existing sign-inIntegration bridgeCloud identity service
PHASE 02Web interface
Selected approach · Two delivery phases

See how the chosen approach fits the systems you have.

03

Actionable handoff

DELIVERY PLAN

Carry the reasoning
into the work.

01

Introduce the bridge

Connect cloud sign-in while keeping existing user and admin access working.

↳ Sign-on integration decision
02

Move to the web interface

Plan when the new web interface will replace the old screens.

↳ Selected two-phase approach
Work stays linked to the reasons behind it

Give engineering a plan with the decisions still attached.

Illustrative deliverables for the sample sign-in modernization project.

Explore the workflow

INSIDE DECISION TRACE

Open the decision.
Read the reasoning.

Decision Trace connects architecture decisions to the requirements, alternatives, and evidence behind them—and the work that follows.What to record in an architecture decision

ARCHANGEL / DECISION DETAIL
Archangel decision detail: the option-constraint matrix compares Okta alone with a PostgreSQL profile store plus Okta. The selected option's rationale and referenced constraints and observations appear below.
Sample mainframe modernization · User-data and sign-in decision · Product capture

A CLOSER LOOK

Why keep user profiles
separate from sign-in?

Okta, an identity service, handles sign-in. A separate database holds the user details and roles the application needs. Decision Trace shows why that approach was chosen.

  1. 01

    See the alternatives

    Compare the options against the same requirements.

  2. 02

    Understand the choice

    Read why the selected approach fits the existing application.

  3. 03

    Follow the evidence

    Follow the reasoning back to the policies and information that shaped it.

Read the example in plain text

Selected: A PostgreSQL database for user profiles, with Okta handling sign-in.

Why: Existing programs need user details and roles beyond sign-in. A separate database keeps those details available while Okta handles authentication.

Rules: Never store passwords as readable text; keep Okta responsible for authentication.

THROUGH TO IMPLEMENTATION

Keep the build
connected to
the decision.

Spot architecture drift as the software changes. Check the build against the agreed design and see which requirements and decisions a change affects.

See how changes are checked How architecture drift happens
AN ILLUSTRATIVE CHANGE CHECK
THE REQUIREMENT

Keep user and admin access
working during the change.

THE PROPOSED CHANGE

Replace the existing sign-in
in phase one.

Check the impact on existing access

Replacing sign-in immediately removes the bridge that keeps existing access working. Check how users and administrators would be affected.

↳ Sign-on integration decision

RUNS WHERE YOU RUN

Your infrastructure.
Your approved models.

Run Archangel in your own cloud or infrastructure, connected to the AI models your organization approves.

Review security & deployment
01

Your environment

Control where Archangel runs and how data moves.

02

Your keys

Use your own API keys for supported AI providers.

03

Your models

Choose the AI models your organization approves.

SEE ARCHANGEL IN ACTION

Bring an initiative.
See the why behind it.

See how your requirements shape the design,
how it gets checked, and what engineering receives.

Request a demo
Evaluate architecture governance on one initiative