Prototype Qualification Criteria
The mandatory gate between a submission and Active–Experimental status
Version 1.0 — Document Owner: Chief Product Officer (CPO) · Public Document
This document defines the mandatory criteria a submission must satisfy before it can be accepted and published as an official Autheo Labs prototype. Every submission to the autheo-labs GitHub organization is evaluated against the requirements, rubric, and disqualifying conditions defined here. No prototype receives Active – Experimental status without passing this qualification process.
What Qualifies as a Labs Prototype
A Labs prototype is any experimental feature, integration, bridge, module, or quantum-native concept that meets all five of the following conditions:
- Not production-ready. Has not passed full QA or CISO security review and is not intended for immediate production deployment.
- No shared production infrastructure. Does not share production keys, validators, node access, or critical infrastructure with the main Autheo network.
- Self-contained within autheo-labs. Exists entirely within the autheo-labs GitHub organization. Does not live in or depend on the main Autheo GitHub organization.
- Defined, testable purpose. Has a clear hypothesis or use case, documented and evaluable.
- Recognized authorship. Authored or sponsored by a recognized Autheo contributor or approved external builder.
What Does NOT Qualify
- Marketing experiments (campaign pages, growth tests)
- Documentation-only submissions without functional code
- Unmodified forks of mainnet code
- Submissions requiring mainnet/testnet infrastructure access (without BUL approval)
Mandatory Pre-Submission Requirements
All six items must be complete before a submission enters CPO review. Missing any item results in the submission being returned without scoring.
| # | Requirement | Detail |
|---|---|---|
| 1 | README complete | Uses the official Autheo Labs README template. Includes purpose, hypothesis, known limitations, and risk level self-assessment. |
| 2 | Experimental disclaimer present | AUTHEO LABS — EXPERIMENTAL disclaimer is in the repository root (README and LICENSE header) and on any UI surfaces. |
| 3 | No production credentials | Codebase contains no production keys, API secrets, validator credentials, or references to production infrastructure. |
| 4 | No mainnet/testnet dependency | Does not reference, modify, or depend on mainnet or testnet deployments. Any exception requires documented BUL approval before submission. |
| 5 | Named Prototype Lead | One named individual designated as Prototype Lead — the single point of accountability through the prototype lifecycle. |
| 6 | CISO security self-review completed | Submitter has completed a self-review against the CISO security checklist (static analysis, dependency scanning, OWASP basics). Findings documented in README. CISO sign-off not required at this stage. |
Qualification Scoring Rubric
Each submission is scored against five dimensions on a scale of 1–3. Maximum score: 15.
Innovation Value
Does this submission explore new capability, integration, or quantum-native concept not already present in Autheo mainnet or testnet?
Incremental variation of existing functionality. Marginal novelty.
Meaningful new capability, integration method, or architectural approach.
Breakthrough or first-of-kind concept. Explores territory Autheo has not addressed.
Hypothesis Clarity
Is the testable purpose clearly defined? What is this prototype trying to prove or demonstrate?
Vague or unclear. Purpose cannot be tested or evaluated objectively.
Defined but incomplete. The intent is understandable but lacks specificity or measurable outcomes.
Specific, testable, and fully documented. A reviewer can determine success or failure against the stated hypothesis.
Isolation Integrity
Is the prototype fully isolated from production infrastructure?
Unclear or partial isolation. Production dependencies may exist or cannot be verified.
Mostly isolated with minor concerns. Shared utilities or libraries referenced but no direct production access.
Fully isolated. No production dependencies. Entirely self-contained within autheo-labs.
Risk Transparency
Are known limitations, bugs, and risk factors honestly documented in the README?
No risk documentation present.
Partial risk documentation. Some limitations noted but coverage is incomplete.
Full, honest risk disclosure. Known bugs, failure modes, security considerations, and limitations are clearly documented.
Roadmap Alignment
Does this experiment align with at least one Autheo strategic goal?
Tangential or unclear alignment. Connection to strategic goals is not evident.
Moderate alignment. Relates to a strategic goal but is not a direct contribution.
Direct alignment with a current roadmap priority. Clear line from prototype to strategic objective.
Review Decisions
| Outcome | Condition | Next Step |
|---|---|---|
| Pass | Score ≥ 10, no disqualifying conditions | Prototype moves to Active–Experimental status and is published. |
| Conditional Pass | Score 8–9, no disqualifying conditions | Submitter given 5 business days to address gaps and resubmit. One resubmission permitted. |
| Reject | Score < 8, or any disqualifying condition | Written rejection with rationale. Submitter may revise and resubmit as a new submission. |
Decisions are issued within 5 business days of a complete submission (post pre-check).
Automatic Disqualifiers
Any of the following result in automatic rejection, regardless of rubric score. These are non-negotiable.
Production credentials in codebase — hardcoded keys, API keys, or node access of any kind.
Mainnet/testnet dependency without BUL approval — depends on live infrastructure without documented pre-approval.
Missing or non-compliant README — README is absent or does not follow the Autheo Labs template.
Missing experimental disclaimer — AUTHEO LABS — EXPERIMENTAL disclaimer not present in repo and on all UI surfaces.
No named Prototype Lead — no single accountable individual identified.
Unmodified copy of existing open-source project — direct copy without meaningful Autheo-specific modification.
Unapproved financial mechanisms — includes token issuance or on-chain value transfer without CISO and Legal pre-approval.
Criteria Review Cadence
This document is a living specification. The CPO reviews and updates qualification criteria on a quarterly basis. Any substantive changes to disqualifying conditions or rubric scoring methodology require CPO approval and are published to the community with a changelog.
Ready to submit a prototype?
Read the Contributor Guide →