HAL Score

HAL Score Assessment

For workflows where individual review does not scale. Twenty-four questions across eight domains. About five minutes. You'll get a HAL Score, maturity level, domain breakdown, recommended governance model, and deployment recommendation.

Nothing is sent anywhere. The assessment runs entirely in your browser.

Not sure if HAL applies? Start with the Loop model →

Your target: … / 40. Recommended for … from the calculator. We've pre-selected that autonomy band below.

Recalculate →

No target score set yet.

Run the Workflow Calculator first — it sizes the minimum HAL Score your system should reach before deployment.

Calculate your target →

0 / 24 answered

First, what does this system do?

This sets the autonomy band. The more a system can do, the higher its required score.

×1.0 Advice System Produces outputs for a human to use. Takes no action of its own. ×1.2 Recommendation System Influences decisions by ranking, scoring, or classifying. A human still acts. ×1.5 Execution System Takes actions in systems of record, within bounded authority. ×2.0 Autonomous System Takes consequential, externally-facing actions with real-world effect.

01 Ownership

Is there a single, named individual accountable for this system?

No. It is owned by a team, committee, or "the platform". Informally: people know roughly who, but it is not recorded. Yes: a named owner is recorded, but no deputy. Yes: a named owner and deputy are recorded and current.

Does the accountable owner have the power to suspend the system immediately?

No. Switching it off requires a change board or vendor. In theory, but it has never been tested and the path is unclear. Yes, but only via a process that takes hours. Yes: the owner can pause it immediately and the kill-switch is tested.

Did the owner formally accept the authority delegated to the system?

No sign-off exists. Verbal or informal agreement only. Signed off once at launch, not revisited. Signed off, recorded in a register, and re-confirmed on schedule.

02 Authority

Is the system's authority expressed as an explicit list of permitted actions?

No. It is described in free text or a prompt only. Loosely: a general description of what it "should" do. Mostly: a documented list with some gaps. Yes: a precise allow-list of concrete permitted actions.

Is authority enforced in code, or only requested of the model?

Only in the prompt: the model is asked to behave. Mostly prompt, with a few technical guards. Enforced at the integration layer for the riskiest actions. Enforced in code at the integration layer for all actions.

Is authority bounded by quantitative limits (value, volume, recipients)?

No quantitative bounds at all. Some informal bounds, not enforced. Key bounds enforced, others missing. Comprehensive, enforced bounds on value, volume, and counterparties.

03 Limits

Are there explicitly prohibited actions the system can never take?

No prohibited-action list exists. A few prohibitions described informally. A documented list, partially enforced. A clear list enforced as hard guard rails.

What happens automatically when a hard limit is reached?

Nothing. Limits are advisory at best. A warning is logged but the action proceeds. The action is blocked but no one is alerted. The action stops, the system pauses, and a human is alerted.

Have the limits been tested adversarially (deliberately trying to breach them)?

Never tested. Tested informally during development. Tested at launch, not since. Tested regularly, including red-teaming, with results recorded.

04 Escalation

Does the system escalate to a human on uncertainty or novel cases?

No. It always proceeds, even when unsure. Sometimes, based on undocumented heuristics. Yes for errors, but not for uncertainty or novelty. Yes: explicit triggers for uncertainty, novelty, limits, and high stakes.

Is each escalation routed to a named role with a response-time expectation?

No defined recipient or SLA. A shared inbox with no SLA. A named role, but no agreed response time. A named role with an agreed, monitored SLA.

Does the system pause the affected action while awaiting a human?

No. It proceeds on its best guess. It proceeds but flags the case for later. It pauses high-risk actions only. It pauses the affected action until a human responds.

05 Evidence

Can any single decision be reconstructed after the fact?

No. Only the final outcome is visible. Partially: outputs are kept, inputs are not. Mostly: inputs and outputs, but not versions or reasoning. Fully: inputs, reasoning, versions, and authority are all recorded.

Is the decision record immutable and time-stamped?

No record, or one that can be freely edited. A mutable log with no integrity controls. Time-stamped logs, but editable by admins. Immutable, time-stamped, tamper-evident records.

Are human touchpoints (reviews, overrides, approvals) captured in the record?

No. Human actions are not logged. Some, inconsistently. Most human touchpoints are logged. All human touchpoints are logged and attributable.

06 Monitoring

Is the system observed in production with health metrics?

No production monitoring. Basic uptime only. Error and volume metrics, but not behavioural drift. Error, escalation, confidence, and drift metrics tracked live.

Do alert thresholds notify the owner of anomalies?

No alerting. Alerts exist but go to an unmonitored channel. Alerts reach the team, with unclear thresholds. Tuned thresholds page the named owner.

Can monitoring automatically pause the system on a severe anomaly?

No. Monitoring only reports. A human must notice and act manually. Auto-pause exists for a narrow set of conditions. Auto-pause is in place for severe anomalies, with review.

07 Review

Is there a scheduled date for formal re-examination of the system?

No review is scheduled. Reviews happen ad hoc when something goes wrong. An annual review is scheduled. A review date and owner are set and tracked.

Does review test whether the original justification for its authority still holds?

There is no review. Review checks performance only, not justification. Justification is considered informally. Review formally re-tests the justification for granted authority.

Can a review re-scope, re-approve, or retire the system?

No mechanism to change or retire it. Changes require a separate, undefined process. Review can recommend changes but not enforce them. Review is empowered to re-scope, re-approve, or retire.

08 Liability

Is it documented which of the system's actions can create legal or financial obligations?

No. This has not been analysed. Understood informally by some staff. Documented for the highest-risk actions. Comprehensively documented and mapped to controls.

Do vendor and customer contracts address autonomous-system actions?

Contracts are silent on AI-driven actions. Generic clauses that do not address autonomy. Some contracts updated, others not. Liability deliberately allocated across the relevant contracts.

Is insurance and disclosure for autonomous actions confirmed?

Neither confirmed. Assumed covered, never verified. One of insurance or disclosure addressed. Insurance confirmed and disclosure obligations defined.

Answer all questions to continue.

Your result

HAL Score

… / 40

Base score: …
Autonomy band: …

Critical gaps

These controls are gates, not averages. A strong overall score does not compensate for any of them.

Domain breakdown

Weakest areas

Address these first to lift your score and close accountability risk.

Suggested improvements

Concrete next steps drawn from the framework guidance.

Deployment recommendation

This is a self-assessment readiness indicator, not legal advice, an audit, or a certification. Scores reflect the answers given; they are claims until evidenced. Note that a completed assessment is itself a governance record. Decide deliberately where it is stored and how deployment decisions refer to it.