> For the complete documentation index, see [llms.txt](https://docs.havl.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.havl.io/getting-started.md). # Getting Started havl is a decentralized human verification layer for AI and robotics. It lets software ask humans for structured judgment when an automated system is uncertain, a decision has meaningful consequences, or a human checkpoint is required by product policy. A havl task can contain an AI output, proposed agent action, visual observation, robotics exception, or another decision payload. The network routes that task to suitable verifiers, collects responses, applies the configured consensus rules, and returns a machine-readable result. havl is designed for two sides of the same network: **clients**, who integrate the Human Layer into products and workflows, and **verifiers**, who perform verification work from anywhere and build reputation over time. ### **Why havl** AI systems are increasingly able to act, not just answer. Yet confidence scores, model guardrails, and deterministic rules cannot resolve every edge case. havl adds a flexible human checkpoint without forcing every company to recruit, schedule, train, and operate its own review workforce. #### Where the Human Layer helps * **Uncertainty:** the model or agent cannot reach sufficient confidence. * **High-impact actions:** a proposed action should be independently approved. * **Context:** the correct decision depends on nuance that is difficult to encode. * **Accountability:** a workflow requires a recorded human judgment. * **Physical-world exceptions:** robotics systems encounter an unexpected situation. The goal is not to put a human in every loop. The goal is to make human judgment available exactly where it adds value. ### **How it works** A typical havl workflow has five stages. 1. **Create a task.** The client sends the content or action to review, instructions, and routing requirements. 2. **Route to verifiers.** havl selects suitable verifiers based on availability, level, reputation, expertise, and task constraints. 3. **Collect judgments.** One or more independent verifiers submit structured responses. 4. **Resolve the result.** havl applies the requested consensus and quality rules. Ambiguous cases can escalate to additional or more qualified verifiers. 5. **Return the outcome.** The client retrieves the result or receives it through a webhook and continues its workflow. This pattern supports synchronous approval gates as well as asynchronous background verification. ### **The human layer** The Human Layer is the combination of people, routing, reputation, incentives, and infrastructure that sits between automated systems and uncertain real-world decisions. It is designed around four principles: * **Human judgment on demand** rather than permanent manual review. * **Risk-based routing** so higher-impact tasks can require stronger verifier credentials. * **Independent consensus** when one opinion is not enough. * **Measurable trust** through XP, reputation, quality monitoring, and Certified Expert status. As AI and robotics become more autonomous, the Human Layer provides a standard escalation surface that applications can call without changing the core machine system. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.havl.io/getting-started.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.