Training

HIOP Fundamentals

Identity, authority, control, evidence. The model is not the system.

Watch Demo START

Curriculum expands with product releases. This page is instruction, not a certificate Hood does not issue.

Course

HIOP Fundamentals

These are the subjects in this course. Request the course for your team. Hood confirms access before a cohort starts.

What HIOP is
Learn how a request is decided before an action runs, and how that decision is kept.
What HIOP is not
See the work HIOP does not take over from the teams that own the system.
Capability does not equal authority
Separate what a system can call from what it is allowed to cause.
The authority chain
Follow a request from the person or system asking through the decision.
Identity of the requester
Identify who is asking before an effect is considered.
Capability versus authority
Compare a tool the system can reach with the permission required to use it.
PRACTICAL CONTEXT

What this means in an operating environment.

HIOP Fundamentals is part of Hood Intelligence training for teams operating or evaluating governed intelligent systems. Training is meant to give technical, product, risk, and operational stakeholders a shared vocabulary before they configure authority.

What Hood is solving

  • Understand the difference between authentication, capability, policy, authority, execution, and evidence.
  • Learn to identify consequential effects and define the resource and scope that policy actually protects.
  • Practice reading an authority decision and the evidence that explains what was requested and what happened next.

Where it fits

The training path is useful before a technical evaluation, during onboarding, or when multiple teams need to agree on who owns policy and approval decisions. It does not substitute for an organization’s legal, security, or compliance program.

How to evaluate it

A good training outcome is not memorizing HIOP terminology. It is being able to take a real workflow and clearly state the actor, target, effect, authority source, approval boundary, execution route, and evidence required afterward.

Start with a bounded use case