Training

Product Training

Evaluation first. License after evidence. Bring your systems.

Watch Demo START

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

Course

Product training

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

CRUSHIA and the three outcomes
Learn how a request can be allowed, held, or denied.
Fossil evidence
See how a completed decision stays attached to the request and the result.
Silicon decision memory
Understand where a decision is retained for later review.
Canonical effects
Name the effect and the resource a policy is actually protecting.
Lessons

Study the lessons in order.

These lessons are open to study. A scheduled cohort is requested through Start or Contact, and Hood confirms that access before the class begins. Progress stays in this browser.

Finish HIOP Fundamentals first. You can still open these lessons.

Start the first lesson

PRACTICAL CONTEXT

What this means in an operating environment.

Product Training 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