Skip to main content

The Framework

New to The Assurance Line? Start with the free Director’s Guide to understand the framework and choose the resources for your board’s work.

Eight domains form a sequence: each answer depends on what came before it. Work through them to establish what your organization knows about its AI, what evidence supports its claims, and where its assurance stops. Each domain is assessed against the same five assurance states.

Explore the purpose, scope, and reasoning behind all eight domains free. Visibility is published in full as a worked example; the other domains include selected control objectives. The Professional Edition includes every objective, supporting evidence, domain-specific assurance criteria, and the standards mapping.

The questions to ask management and the answers that warrant a closer look are in The Board AI Questions. Free preview; complete questions in the Board Edition.

The Rules of the Line

  1. 1Results are never averaged.Each domain stands on its own result. A strong score in one does not make up for a weak one in another, and no overall score is given.
  2. 2Nothing is more assured than what it rests on.A domain’s result is capped at the lowest result of any domain before it on the Line. If the inventory is only Ad hoc, a claim that most systems are independently tested rests on a count nobody can trust, and the result says so.
  1. VIS

    1. Visibility

    The questionWhat AI are we actually running?An organization needs to know its inventory of AI systems: what they are, how each was developed, procured, or activated, and how many are running. Every assurance activity that follows depends on that answer. Complete free example7 control objectives
  2. ACC

    2. Accountability

    The questionWho is answerable for it?Every AI system needs an accountable role held by a named individual, and the board needs a record of what it delegated and what it kept. Accountability assigned to a committee tends to dissolve at the moment it is tested. Free preview7 control objectives · 2 previewed
  3. VAL

    3. Value

    The questionWhy are we running it?Boards are shown the benefit case before deployment. What matters afterward is whether those benefits were realized, what they proved to be worth, and what the system costs to keep running. Free preview6 control objectives · 2 previewed
  4. EXP

    4. Exposure

    The questionWhat could go wrong, and who could be affected?The worst realistic outcome from an AI system, the path by which it would reach the organization, and what actually stands in the way. The risk register records that judgment; this domain tests whether it holds. Free preview7 control objectives · 2 previewed
  5. FND

    5. Foundations

    The questionWhat is it built on?Where the data came from, whether the organization was entitled to use it for this purpose, whose model is underneath, and how anyone would know if its behavior changed. Free preview8 control objectives · 2 previewed
  6. OBL

    6. Obligations

    The questionWhat are we required to do?The process of knowing what applies, keeping up as it changes, and testing compliance rather than assuming it. This includes obligations arising from where customers are located, as well as where the organization operates. Free preview8 control objectives · 2 previewed
  7. ASR

    7. Assurance

    The questionHow do we know any of this is true?Everything the previous six domains produce is assertion until somebody independent has tested it. This domain establishes who tested what, what they found, and what happened next. Free preview9 control objectives · 2 previewed
  8. RES

    8. Resilience

    The questionWhat happens when it goes wrong?How the organization finds out, how quickly, who has authority to stop the system, and what happens to the people already affected. Free preview8 control objectives · 2 previewed