Micro1 is a data lab for frontier AI models. They connect domain experts to models, and that work turns into expert human data, real-world training environments, and contextual evaluations. AFiR wraps those expert sessions, AI interviews, and evaluation passes in signed receipts. A buyer can check those receipts without having to trust platform logs.
Here's what that gets you: every Micro1 Certified expert contribution carries independent proof of its conditions. That covers eligibility, the session itself, which tools were declared, the task and rubric, the output, the QA chain, and where the data came from. Micro1 produces the expert data. Hive signs the conditions and the output 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 evaluation infrastructure Micro1 already runs. For each integration point, you'll see what Micro1 has today, what Hive signs, and what a downstream buyer can check on their own.
| Integration point | What Micro1 has | What Hive signs | What the buyer verifies |
|---|---|---|---|
| Expert onboarding / eligibility | Vetted domain experts, institutional knowledge, contextual task pools. | An eligibility receipt showing the credential and eligibility bar was cleared. No raw identity documents get exposed. | expert_eligibility |
| AI interview / session | Interview and evaluation sessions with experts and candidates. | A session envelope binding start, continuity, and completion of the session. | session_hash |
| Task assignment | Contextual, domain-specific tasks; benchmarks; red-team prompts. | A hash of the task and scoring rubric bound to the assignment. | task_hash · rubric_hash |
| Declared tool / model use | Tooling and model access within the evaluation environment. | The declared tool/model-use scope, making undisclosed assistance detectable. | tools_declared |
| Expert review / evaluation pass | Expert review passes, failure taxonomies, drift control. | AFiR binds each review move to the output it produced. | output_hash |
| QA / reviewer chain | Quality controls, reviewer sign-off, re-review of weak items. | A QA/reviewer-chain receipt bound to the contribution it cleared. | qa_pass |
| Dataset / eval export | Packaged evaluation datasets and feedback loops delivered to labs. | An export/lineage receipt linking rows to their signed conditions. | dataset_export_id |
These map onto expert and evaluation work that already happens. Add a signature layer to the pipeline you already run, and each contribution 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_eligibilityTie together the start, the middle, and the end of the interview or evaluation session, so a buyer can see the contribution came from one uninterrupted session.
session_hashRecord which tools and models were declared in scope. That makes undisclosed help harder and riskier to hide. It's not impossible to hide, but it becomes detectable.
tools_declaredFingerprint the contextual task and rubric, then bind the output with AFiR or AFiR-Stream. That ties the declared conditions to the contribution the buyer actually receives.
task_hash · output_hashSign off on the review step, showing which reviewer pass cleared the contribution, so the QA chain travels with the deliverable as real evidence, not just something sitting in an internal system.
qa_passCarry the history through the exported evaluation dataset, showing which signed conditions produced which rows, so that history survives packaging and resale.
dataset_export_idOnce the receipts exist, certification 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.
Certified human-conditioned expert work becomes its 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 evaluation followed the declared rubric or task standard, with a signed receipt, not just a score sitting in a dashboard.
rubric_conformanceA history graph for an assembled evaluation pack, where every contributing expert condition is linked and signed, so a model buyer can check the whole chain from end to end.
provenance_graphAgents can buy verified expert work or evaluation 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
Click Sign the receipt. 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 expert data. It shows how a signed Micro1 evaluation receipt reads once it carries an AFiR receipt. Click Verify receipt to run the simulated check.
$ hive verify M1-CERT-4B8E1D7A → fetching receipt … ok → afir_signature … valid → pq_signature (ml-dsa-65) … valid → session_hash / rubric_hash bound … match → qa_pass reviewer 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 system 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 contribution 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 receipt adds an administration record to a certified contribution before that contribution is shown to a buyer. It is finished in code, absent from deployment, and the sample runs make that distinction visible.
A certified human contribution carries more weight when its assessment was arranged before the person faced it. The record connects a specific evaluation attestation to the declared way that evaluation was administered. It stores a test set fingerprint at or before disclosure of the contents to the contributor and at or before the opening of the evaluation period. An independence class is recomputed from the declared relationship and separation of duties, rather than supplied by the caller. The administrator and the stated working separation remain assertions in the record, not facts independently verified by this service.
What it does not do. This receipt never carries a test score or result, and it cannot prove that the set was suitable or representative, that a contributor never got material elsewhere, that the method was sound, or that the administrator was capable. It does not grant accreditation or certification, is not an audit opinion, and has no current recognition from a standards body, regulator, or insurer.
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 micro1 certified proof