Human–AI Systems Architecture

Using AI is one thing. Operating a human-AI system is another.

Human–AI Systems Architecture is Bravura Works’ framework for designing the operating environment around AI: what governs, who has authority, how work moves, what must be verified, how failure is recovered, and how the system survives change.

Explore the framework

AI can work perfectly and the system can still fail.

A model can give you a beautifully written answer from the wrong policy. An automation can execute flawlessly after the rule it was built around has changed. An agent can have permission to act without the authority to decide. That is the territory HASA is built for: the spaces between tools where authority, state, evidence, judgment, handoffs, recovery, and stewardship determine whether the system actually works.

Tools change. Operating principles have to last.

Knowing how to use the tool is not the same as knowing how to operate the system around it. Someone still has to decide which source governs, what state the work is in, where human judgment belongs, what gets checked, what happens when the AI is wrong, and whether another person could safely take over tomorrow. HASA treats those questions as architecture, not cleanup.

Human–AI Systems Architecture

What the discipline covers.

01

Authority, evidence & provenance

Know which source governs a decision, why it governs, and what happens when that source changes.

In the curriculum

Learners work with source authority, evidence lineage, provenance, time-sensitive truth, and the difference between information that is easy to find and information that actually governs a decision.

In practice

They learn to resolve conflicting sources, explain why one controls, preserve the evidence behind that conclusion, and design what should happen when the governing source changes.

02

State, workflows & boundaries

Make the work reconstructable: what happened, what is happening now, what can happen next, and where the system must stop.

In the curriculum

Learners model workflows as explicit states, transitions, events, tool contracts, boundaries, and recovery behavior, including the places where automation or AI autonomy must stop.

In practice

They turn vague processes into something another person can inspect and operate: clear states, handoffs, allowed actions, stop conditions, exceptions, and recovery paths.

03

Human judgment & decision rights

Keep human judgment where authority, accountability, consent, or real-world consequence requires it.

In the curriculum

Learners examine decision rights, escalation, bounded autonomy, organizational consequences, and the difference between being technically able to act and being legitimately authorized to decide.

In practice

They decide where AI can assist or act, where a person must retain judgment or accountability, and how exceptions get back to the right human owner.

04

Verification, evaluation & recovery

Define what success has to prove, catch failure before it travels, and make recovery part of the design.

In the curriculum

Learners work with ground truth, evaluation, calibration, observability, incident response, reliability, and recovery as parts of the operating design.

In practice

They define what success has to prove, connect outputs and actions to evidence, detect when the system is wrong, and design a credible path back to a known-good state.

05

Privacy, security & responsible autonomy

Decide what the system may access, infer, retain, change, or disclose, and where consequence requires approval.

In the curriculum

Learners connect privacy and security to actual system behavior: identity, permissions, least privilege, sensitive-data boundaries, and high-impact or irreversible actions.

In practice

They decide what a system may access, infer, retain, disclose, or change, and where consequence requires escalation or human approval.

06

Stewardship, succession & transfer

Build systems other people can understand, maintain, migrate, and inherit without borrowing reliability from one creator’s memory.

In the curriculum

Learners treat lifecycle, migration, portability, multi-human operation, external audit, successor handoff, and eventual retirement as architecture rather than aftercare.

In practice

They design systems that can survive changed tools, changed people, changed rules, and eventual handoff without depending on one creator’s memory to keep them alive.

THE CURRICULUM BEHIND THE FRAMEWORK

Built to be learned, practiced, and transferred.

HASA is backed by a developed 26-week curriculum: 24 core instructional weeks plus two regulatory practicums. It starts with the fundamentals people need to operate reliably, including authority, modeled reality, retrieval, memory, and workflow state, then builds toward automation, bounded autonomy, governance, recovery, evaluation, organizational consequence, portability, stewardship, and handoff.

The progression is cumulative: learn to operate reliably, then build deliberately, then architect systems that can survive change and transfer to others.

A progression of practice

Operator → Builder → Architect

Operator

Work reliably inside human-AI systems by locating authority, understanding state, verifying outputs, handling exceptions, and preserving human judgment.

Builder

Compose and improve human-AI workflows by connecting sources, tools, actions, checks, handoffs, and recovery paths into systems that can be operated deliberately.

Architect

Design the larger operating environment by resolving authority, boundaries, governance, evaluation, privacy and security, failure recovery, evolution, and eventual transfer to other people or systems.

HASA in practice

What changes in practice.

Five policies. One decision.

Your AI finds five plausible versions of a policy. Which one governs this decision today? HASA forces the harder question: what is authoritative, what evidence makes it authoritative, and what should happen when that authority changes.

Permission is not authority.

An AI system may be technically able to approve a refund, send a message, change a record, or delete a file. That does not mean it has the right to decide. HASA separates capability from authority and makes the boundary explicit.

Can someone else run it?

If a workflow only works because its creator remembers the hidden rules, the system is borrowing reliability from a person's memory. HASA treats reconstructability, recovery, and succession as architecture, not cleanup.

A person sketches a human-AI systems diagram at a desk, emphasizing human judgment in system design.

Who it is for.

HASA is for people who have moved past asking what AI can do and are now responsible for making AI-enabled work dependable: operators, system builders, knowledge and operations practitioners, product and AI-enablement leaders, consultants, and teams accountable for how the work behaves over time.

Explore the thinking.

Systems That Work takes many of the same questions into practical essays about operations, knowledge, governance, human judgment, and AI.

Read Systems That Work

Human–AI Systems Architecture

The demo is the easy part.

The harder work begins when the demo ends: rules change, exceptions appear, people hand work off, tools fail, and someone has to explain what happened. Human–AI Systems Architecture is built for that part.