Deccan AI produces super-accurate post-training data, RL environments, and expert evaluations for frontier models. People curate it on a purpose-built platform with linters, compilers, LaTeX editors, and LLM validators, backed by high-touch QC. AFiR wraps those workflows in signed receipts. A buyer can check those receipts without having to trust platform logs.
Here's what that gets you: every curated data pack, environment run, and evaluation carries independent proof of its conditions. That covers expert eligibility, the task and rubric, validator evidence, the human review path, the output, QA escalation, and where the data came from. Deccan produces the quality. Hive signs the conditions and the trail. Keeping those two jobs separate is the whole point.
You can do this yourself today. Pay with x402, request an activation key, or open OriginProof and run a sample receipt. This brief should answer your questions on its own. No meeting required.
Technical integration brief
This is a thin signature layer that sits on top of the data, QC, and evaluation infrastructure Deccan already runs. For each integration point, you'll see what Deccan has today, what Hive signs, and what a downstream buyer can check on their own.
| Integration point | What Deccan has | What Hive signs | What the buyer verifies |
|---|---|---|---|
| Expert onboarding / eligibility | Exceptional vetted experts, domain-specific talent pools. | An eligibility receipt showing the credential and eligibility bar was cleared. No raw identity documents get exposed. | expert_eligibility |
| Task / rubric assignment | Domain-specific tasks, gold standards, scoring rubrics. | A hash of the task and scoring rubric bound to the assignment. | task_hash · rubric_hash |
| Platform validator evidence | Linters, code compilers, LaTeX editors, LLM validators in-platform. | A receipt binding which validators ran and their pass state to the item. | validator_evidence |
| Human review path | High-touch QC, expert review passes, drift control. | AFiR binds each human review move to the output it produced. | review_chain · output_hash |
| QA escalation | Re-review of weak items, escalation and sign-off ladders. | A QA-escalation receipt bound to the item it cleared. | qa_pass |
| RL environment run | Purpose-built RL environments and agentic task runs. | An environment-run receipt binding the transcript to its declared setup. | env_transcript |
| Dataset / eval export | Curated data packs and evaluation exports delivered to labs. | An export/lineage receipt linking rows to their signed conditions. | dataset_export_id |
These map onto data, QC, and evaluation work that already happens. Add a signature layer to the pipeline you already run, and each item becomes something a buyer can check for themselves. That's portable evidence, not just a line in a dashboard.
Confirm the expert cleared the credential and eligibility bar set for the task, without exposing the identity documents behind it.
expert_eligibilityFingerprint the domain task and its scoring rubric or gold standard, tied to the assignment, so the declared bar travels with the deliverable.
task_hash · rubric_hashRecord which platform validators ran (linter, compiler, LaTeX, LLM validator) and their pass state. That makes silent QC gaps detectable and much harder to hide.
validator_evidenceTie the high-touch human review path to the item, then bind the output with AFiR or AFiR-Stream. That ties the declared conditions to the item the buyer actually receives.
review_chain · output_hashSign off on the escalation step, showing which reviewer ladder cleared the item, so the QA chain travels with the deliverable as real evidence, not just something sitting in an internal system.
qa_passCarry a signed environment-run transcript and history through the exported data pack, showing which signed conditions produced which rows, so that history survives packaging and resale.
env_transcript · dataset_export_idOnce the receipts exist, quality stops being just an internal control and becomes something you can sell. These are strategic options worth reviewing with counsel. They're not claims that any of this ships today.
Verified data packs and human-curated work become their own named product line, a process a buyer can prove was human-conditioned and price a premium against.
product: OriginProofA portable, signed record of an expert's cleared credentials and skills that follows the work across engagements. It's reusable, it can be revoked, and a buyer can check it.
attestation: portableProve an item followed the declared rubric and QC ladder, with a signed receipt, not just a score sitting in a dashboard.
rubric_conformanceA history graph for an assembled data or evaluation pack, where every contributing condition and environment run is linked and signed, so a model buyer can check the whole chain from end to end.
provenance_graphAgents can buy verified expert evaluation or data on demand. An agent pays with x402 at the moment proof is needed, and gets back a signed receipt tied to the human-conditioned work it just bought.
agent_settlement: x402See it sign
Pick a Deccan-style workflow, then click Sign the receipt. The workflow sets the task and validator evidence. Each condition signs in turn, and the live receipt fills in field by field. Nothing here claims a route. It only confirms the conditions the work was made under.
Explorer preview
This is an illustrative mock-up with made-up values, not real Deccan data. It shows how a signed Deccan data-pack receipt reads once it carries an AFiR receipt. Click Verify receipt to run the simulated check.
$ hive verify DQ-PACK-9C42A1F7 → fetching receipt … ok → afir_signature … valid → pq_signature (ml-dsa-65) … valid → rubric_hash / validator_evidence bound … match → env_transcript hash … match → high_touch_qc review chain … intact ✔ receipt verified · conditions attested
Why independence matters
Both have their place. The difference is who you have to trust for the record to mean something to a downstream buyer.
“Our platform recorded it.”That's a useful operational fact, but the buyer has to trust the same platform that produced the record. The record-keeper and the interested party are the same company.
Evidence that checks out without the platform.This is a signed receipt a buyer checks against a public key. It's proof that travels with the data pack right into the buyer's own pipeline.
Start signing
Every path is self-serve and real. Settle with x402, request an activation key, or open OriginProof and run a sample receipt.
Sources & grounding
Public, organization-level grounding for the framing above. No individuals named; claims are kept to what these public materials state.
This new receipt gives a sampled quality review a record of how its evaluation was set up. It answers in production right now, and the run below proves it end to end.
Quality sampling is stronger when a reviewer can see how the sample reached its assessment. The receipt pairs one labeled work evaluation with the declared administration arrangement. It fingerprints the sample set before its contents go to the people being assessed and before the review period opens. Its independence class is recomputed from the stated relationship and separation of review duties, rather than accepted as caller text. The claimed administrator and the described working arrangement stay as assertions that this service does not independently verify.
What it does not do. It carries no quality score or result and does not decide whether the sampled rows represent the full data pack, whether the set was appropriate, or whether the evaluation method was adequate. It also cannot establish that items never reached a contributor elsewhere or that the administrator was competent, and it is not a certification, accreditation, or audit opinion that standards bodies, regulators, or insurers currently recognize.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.
Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.
Search the explorer for Deccan quality proof