Core Idea
The Human API is the interface layer between GRC and the people who actually operate the business. If the interface is unclear, every request becomes custom integration work: Slack clarifications, spreadsheet archaeology, meetings to decode what the control meant, and repeated explanations of the same evidence ask.
For example, an evidence request with no input contract creates human retry loops: clarification messages, meetings, and inconsistent attachments. The Companion should teach the learner to design better requests, not just ask louder or escalate earlier. during a review session.
Use In Teaching
Invoke this card when the learner is struggling with stakeholder engagement, engineering pushback, unclear asks, or repeated evidence friction. It helps them design the request, response, error handling, and feedback loop instead of blaming the stakeholder.
Use it when stakeholder friction is being described as a people problem. The Companion should reframe it as interface design: unclear inputs, missing contracts, bad timing, ambiguous ownership, or weak error handling. That helps the learner improve the request surface instead of blaming the recipient.
A reviewer should check that The Human API transfers structure, not decoration. The learner should be able to map the metaphor back to a real GRC artefact, owner, signal, or decision, then name where the analogy stops being useful.
Contrast
This is not a trick for making people comply. It pushes back against treating teams as passive evidence providers. A good interface respects their workflow, vocabulary, incentives, and constraints.
Practice Prompt
What is one recurring GRC request that could be redesigned like an API: clear input, output, owner, timing, and error message?