PoQ Workflow
Every PoQ project has the same basic shape:
| Step | Outcome |
|---|---|
| 1 | Define the work. |
| 2 | Have validators review it. |
| 3 | Produce a report that can be reviewed later. |
1. Originate
Origination turns a dataset into reviewable work.
You start with intent: what needs review, what evidence validators should see, and what "good" means. That intent can be written as poq.md, then turned into poq.toml.
The project specification in the poq.md file defines the actual workload fed into the system:
| Spec area | Examples |
|---|---|
| Workload definition | Inputs, merged data shape, validation UI, validator credentials and routing, escalations, and more |
2. Validate
Validation is the human and agentic expert review step.
Validators claim assigned datapoints, inspect the evidence, and answer according to the rubric. The UI and API present various modalities like choices and numeric scales for assessing.
When enough assessments have been gathered, the engine computes consensus. Strong agreement can finalize the datapoint. Weak signal can trigger escalation and create more validation slots.
See Consensus for the mechanics.
3. Attest
Attestation turns assessments into a durable artifact.
Once a datapoint is terminal, the engine stores the final outcomes and builds the report data used by the project's PoQ report. The report is the thing a customer, auditor, or downstream system can inspect later.
Anyone can:
| Action |
|---|
| Inspect what was reviewed |
| See how validators answered |
| Check the consensus outcome |
| Use the report downstream |