# DISCOVER Capability and Badge Evidence Model

## Implementation contract

**Normative configuration:** `config/DISCOVER-Capability-Mastery-Criteria.v1.json`  
**Model ID:** `discover-capability-mastery-criteria`  
**Criteria version:** `1.0.0`  
**Effective date:** 2026-07-20

Build the Capabilities and Mastery page from the versioned JSON. Do not duplicate the criteria in application code, award a badge from a click, or ask an AI model whether someone is competent. The application calculates progress from admissible records and valid reviews; a qualified, named human makes the award decision.

The model contains 17 capability domains, three developmental levels per domain, three observable criteria per level, and one six-criterion global capstone. That is 153 domain criteria plus six capstone criteria. The fourth displayed level, **AI Agent Orchestration Master**, is a global capstone rather than an automatic fourth tier within each domain.

Use `MUST`, `MUST NOT`, `SHOULD`, and `MAY` in this document as implementation requirements.

## What an award means

A DISCOVER award means only this:

> The named human reviewer or reviewers approved the cited, current evidence against the pinned DISCOVER criteria version within this workspace.

It is not licensure, certification, continuing-education credit, an academic award, IRB or HRPP review or approval, an exemption or regulatory determination, investigator or principal-investigator status, scientific or clinical validation, employer or institutional authorization, permission to access data or recruit participants, authorization to conduct research or deploy an intervention, clinical privilege, or permission to practice. A DISCOVER reviewer is assessing evidence against these developmental criteria—not acting as an IRB, HRPP, privacy board, scientific review committee, regulator, credentialing body, sponsor, employer, or institutional authorizing official unless that separate official process is independently documented outside the badge.

Show the complete disclaimer on the Capabilities page, every badge detail, every reviewer decision, every portable export/import and share preview, every print view, and the capstone award. Do not use seals, state-board, IRB, regulator, sponsor, university, or institutional-approval imagery; professional credential abbreviations; investigator-status labels; or language such as “licensed,” “certified,” “IRB approved,” “HRPP approved,” “exempt,” “principal investigator,” “scientifically validated,” “clinically validated,” or “authorized” as a claim arising from a badge.

## Capability domains

| ID | Display name | Currency | Typical reviewer knowledge |
|---|---|---:|---|
| `ai_literacy` | AI Literacy | 12 months | AI literacy and responsible AI |
| `prompt_design` | Prompt Design | 18 months | prompt design and quality review |
| `evidence_informed_research` | Evidence-Informed Research | 18 months | research methods and evidence appraisal |
| `critical_thinking` | Critical Thinking | 24 months | critical thinking and decision quality |
| `structured_problem_solving` | Structured Problem-Solving | 24 months | problem-solving and quality improvement |
| `workflow_design` | Workflow Design | 18 months | workflow design and operations |
| `project_management` | Project Management | 24 months | project management and delivery |
| `data_privacy_stewardship` | Data and Privacy Stewardship | 12 months | privacy, data governance, and security |
| `ethical_ai_practice` | Ethical AI Practice | 12 months | responsible AI, ethics, and accessibility |
| `edena_governance` | EDENA Governance | 12 months | EDENA, governance, and risk |
| `agent_supervision` | Agent Supervision | 12 months | agent governance, safety, and operations |
| `multi_agent_orchestration` | Multi-Agent Orchestration | 12 months | orchestration, agent governance, and safety |
| `knowledge_base_development` | Knowledge-Base Development | 18 months | knowledge management and evidence governance |
| `automation_design` | Automation Design | 12 months | automation, safety, and operations |
| `artifact_creation` | Artifact Creation | 24 months | communication, accessibility, and quality review |
| `evaluation_quality_improvement` | Evaluation and Quality Improvement | 18 months | evaluation, measurement, and quality improvement |
| `role_specific_professional_development` | Role-Specific Professional Development | 24 months | healthcare research and innovation leadership, research methods or innovation governance, professional development, and role/authority boundaries |

The reviewer tags are matching aids, not credentials. The reviewer record must explain the person’s actual qualification basis for the evidence reviewed. A title, degree, license, investigator appointment, organizational affiliation, system access, IRB membership, or seniority does not satisfy a criterion by itself. Role-specific evidence should be matched to the actual activity—for example research methods, implementation, community engagement, responsible innovation, data governance, or research administration—and not to a generic job-title proxy.

## Developmental levels

### Basic

The user performs a bounded task with guidance, explains important limits, and records a safe human review. The default evidence minimum is one distinct non-starter mission and one distinct artifact. Every Basic award requires at least one named-human reviewer.

### Intermediate

The user selects and adapts a method independently across more than one task, compares results, and applies governance consistently. Basic must be current. The default evidence minimum is two distinct missions and two distinct artifacts. Every Intermediate award requires at least one named-human reviewer.

### Advanced

The user designs, supervises, evaluates, and improves a reusable approach while handling failure, risk, and transfer to accountable humans. Intermediate must be current. The default evidence minimum is three distinct missions and three distinct artifacts. The approving reviewer must be independent of the submitted work: they cannot have been its sole author, operator, or approver.

The exact observable criteria and any domain-specific evidence types are in the JSON. All criteria in the requested level are conjunctive: the engine MUST NOT average away a missing safety or governance criterion.

## Evidence admission

### Eligible evidence

Admissible evidence is saved, attributable, inspectable, dated, purpose-bound, and mapped to one or more criterion IDs. Eligible types include completed missions, reviewed artifacts, source appraisals, versioned assessments, reviewer observations, governance receipts, agent-run receipts, evaluation reports, project records, workflow definitions, automation test reports, knowledge-base change sets, evidence-linked reflections, and portable artifact exports.

Every evidence record MUST contain the required fields named in `evidencePolicy.requiredEvidenceFields`. In particular, it needs:

- immutable evidence ID and type;
- exact criterion mappings;
- mission and artifact references when applicable;
- provenance type;
- observed and submission dates;
- data classification, EDENA tier, FRAME status, and active hat;
- a permitted locator and integrity hash;
- a summary that does not reproduce sensitive payloads;
- limitations; and
- the candidate’s attestation.

One underlying event may support several criteria when every mapping is explicit. It counts only once toward distinct mission and artifact minimums. Evidence does not need to contain the whole artifact; the badge ledger SHOULD retain minimized metadata, a permitted locator, and a hash.

### Evidence that never earns a badge

The engine MUST exclude:

- clicks, page views, checked boxes, launches, and elapsed time;
- unadopted Starter records;
- walkthroughs, tutorials, demos, copied sample answers, and unchanged templates;
- synthetic exercises presented as real outcomes;
- AI self-attestations or AI decisions about competence;
- unreviewed AI or human drafts;
- a title, degree, license, affiliation, access right, or seniority used as a proxy for performance;
- duplicated evidence counted as separate work;
- self-review; and
- evidence containing prohibited or unauthorized data.

Starter content may become ordinary work only after the user deliberately adopts it, materially completes it with authentic evidence, takes it through evaluation, and obtains the required review. Preserve the Starter origin in provenance even after adoption. A simulation may demonstrate a safety test, failure path, or recovery behavior, but it cannot by itself prove a real-world outcome or satisfy the capstone’s authentic-mission requirement.

### Governance and safety evidence

Every earned level MUST have current evidence of:

- EDENA classification and reason;
- FRAME possible-pathway or unresolved status;
- TRACE provenance evidence, or a recorded reason it is not applicable;
- PROBE plan, or a recorded reason it is not applicable;
- ORBIT charter for agent-supported work, or a recorded reason it is not applicable;
- active hat and authority boundary;
- data classification;
- named-human review;
- limitations and uncertainty;
- safe destination or explicit local-only state; and
- correction and stop routes.

Apply the same data-boundary policy to evidence capture, badge calculations, search, export, backup, and logs. Reject unsafe content without echoing it. Never copy PHI, personnel information, secrets, or prohibited operational data into a badge record to make an award look stronger.

## Named-human review

An automated validator may say that a submission is complete. It cannot approve, reject, restore, revoke, or renew mastery. A generative model may help summarize submitted evidence, but its summary is clearly labeled and is not the decision.

Each review MUST identify a real person and store all fields in `reviewerPolicy.requiredReviewerFields`, including the reviewer’s relationship to the candidate, qualification basis, conflict declaration, exact criteria and evidence reviewed, decision, rationale, limitations, date, optional expiry, and attestation hash.

Enforce these rules:

1. The candidate cannot review their own evidence.
2. An AI, anonymous committee, shared account, or invented persona cannot be a reviewer.
3. The reviewer must explain why they are competent to assess the submitted work. Job title alone is not enough.
4. A disclosed conflict is evaluated under the edition’s policy. A blocking conflict invalidates that review.
5. Institutional separation-of-duties and reviewer requirements override the personal defaults when more restrictive.
6. A material evidence correction invalidates the previous approval for affected criteria and opens a new review.
7. An appeal uses a different qualified human. The original review remains visible in history.
8. Review of role-specific development confirms evidence against DISCOVER only. It never grants role authority, certification, investigator or principal-investigator status, IRB or HRPP approval, an exemption or regulatory determination, scientific validation, institutional authorization, clinical privilege, or employment standing.

Basic and Intermediate require at least one valid named reviewer. Advanced requires at least one independent named reviewer. The global capstone requires two distinct reviewers: one role/domain reviewer and one independent governance-and-safety reviewer. Neither may be the candidate; the safety reviewer cannot be a participant whose own orchestration work is under review.

## Implementable data model

Use append-only events and materialized current state. A suggested SQLite representation follows. Exact names may change, but the invariants may not.

### `capability_models`

- `model_id`, `schema_version`, `criteria_version`, `effective_at`
- `source_hash`, `installed_at`, `superseded_at`
- immutable copy of the criteria JSON or a verified package locator

### `capability_evidence`

- required evidence fields from the JSON
- `candidate_id`, `workspace_id`, `role_lane_id`
- `evidence_version`, `supersedes_evidence_id`
- `state`, `created_at`, `updated_at`, `expires_at`
- no sensitive artifact payload

### `capability_evidence_criteria`

- `evidence_id`, `criterion_id`, `mapping_reason`, `created_by`, `created_at`
- composite uniqueness on evidence version and criterion

### `capability_reviews`

- all required reviewer fields from the JSON
- `candidate_id`, `domain_id`, `level_or_capstone_id`
- `review_version`, `supersedes_review_id`, `state`

### `capability_review_evidence`

- `review_id`, `evidence_id`, `criterion_id`, `disposition`, `comment`

### `capability_events`

- `event_id`, `candidate_id`, `workspace_id`, `event_type`
- `actor_type`, `actor_id`, `occurred_at`
- `criteria_version`, `affected_ids`, `reason_code`
- `before_hash`, `after_hash`, `receipt_id`
- minimized metadata only

### `capability_current_state`

- `candidate_id`, `domain_id`, `current_level`, `badge_status`
- `criteria_version`, `progress_percent`, `unmet_gates_json`
- `earned_at`, `last_validated_at`, `renewal_due_at`
- `next_challenge`, `recalculated_at`, `state_hash`

### `criterion_current_state`

- `candidate_id`, `criterion_id`, `satisfied`
- `eligible_evidence_count`, `approved_evidence_count`
- `blocking_reason`, `last_validated_at`, `evidence_set_hash`

### `capstone_current_state`

- `candidate_id`, `status`, `criteria_version`
- `prerequisite_snapshot_hash`, `reviewer_set_hash`
- `earned_at`, `last_validated_at`, `renewal_due_at`
- `progress_percent`, `unmet_gates_json`, `next_challenge`

Use foreign keys to the owning workspace and role lane. A cross-workspace evidence reference MUST fail closed unless an explicit, permitted portable import is validated. Do not use a display filter as the workspace boundary.

## Deterministic calculation

### Criterion calculation

For each criterion:

1. Load evidence mappings for the candidate and pinned criteria version.
2. Exclude evidence that is deleted, withdrawn, revoked, expired, superseded, duplicated, prohibited, or failed by a current review.
3. Verify required fields, integrity hash, permitted locator, governance signals, data boundary, and evidence type allowed by that criterion.
4. Find a current, non-conflicted named-human approval that explicitly covers both the criterion and evidence.
5. Set `satisfied=true` only when at least one admissible evidence item and its required review pass every gate.

An evidence-count threshold cannot compensate for a missing required criterion.

### Level calculation

For a domain and requested level:

1. Confirm the prior level is current when required.
2. Confirm all three criteria for the level are satisfied.
3. Count distinct eligible missions and artifacts across the submission using underlying record IDs, not evidence-row count.
4. Confirm the level’s named-human reviewer minimum and independence rule.
5. Confirm governance, safety, currency, authority-expiry, and unresolved-correction gates.
6. Set `earned` only when every gate passes. Otherwise use `in_progress`, `review_pending`, `expired`, `suspended`, or `revoked` and show the exact reason.

Calculate progress as:

```text
round(100 × satisfied required criteria ÷ total required criteria)
```

Display prerequisite, mission/artifact minimum, review, governance, and currency gates separately. A user can have 100% criterion coverage and still be `review_pending`; do not label that state earned.

### Next challenge

Choose the next challenge deterministically:

1. blocking correction, revocation, data, safety, or governance issue;
2. expired prerequisite or reviewer approval;
3. unmet prior level;
4. first unmet criterion in JSON display order;
5. distinct mission or artifact minimum;
6. named-human review;
7. renewal task; or
8. the next level or capstone when all current requirements pass.

Write the challenge in direct language and link to the missing record or action. Do not recommend a clinical task, consequential action, or data access outside the person’s verified role and authority.

## Dates, currency, and expiry

Store `observedAt`, `submittedAt`, `reviewedAt`, `earnedAt`, `lastValidatedAt`, and `renewalDueAt` as timezone-aware ISO 8601 values. The renewal date is the earliest of:

- the award date plus the domain currency period;
- an evidence-specific expiry;
- reviewer-specified expiry;
- authority expiry affecting the work; or
- a mandatory revalidation trigger.

Mandatory triggers include a criteria major-version change, material role/hat change, material policy or regulatory change, material model/tool/permission change, safety/privacy/integrity incident, reviewer or evidence revocation, and discovery of false or misattributed evidence.

On expiry, retain the historical award and its receipt, remove it from current-capability totals, recalculate dependent levels and capstone eligibility, and show the exact renewal need. Do not silently extend an award because the user revisited its page.

## Correction, deletion, revocation, and recalculation

Every evidence and review mutation is an append-only event. The current state is a deterministic materialization, not an editable achievement flag.

On add, correction, withdrawal, deletion, expiry, review change, authority expiry, governance reclassification, or criteria migration:

1. Load immutable events for the candidate and criteria version.
2. Remove invalid or superseded records from the current evidence set without deleting history.
3. Re-run every affected criterion, domain level, and capstone dependency.
4. Downgrade, expire, suspend, or revoke current awards when requirements no longer hold.
5. Write a before-and-after receipt with affected badges, reason, event IDs, actor, time, and appeal or recovery route.

A corrected artifact becomes a new evidence version linked to the old record. It does not overwrite the historical evidence that the reviewer saw. A material correction requires a new review.

Permitted deletion removes the payload and locator and leaves only the minimum nonsensitive tombstone and integrity receipt needed to explain recalculation. Revocation should be criterion-specific when possible and cascades to dependent levels and the global capstone. Badge revocation is a workspace evidence correction; it must not be presented as a decision about licensure, employment, discipline, or professional standing.

Restoration is never automatic. It requires current eligible evidence, a new named-human review, and a restoration receipt.

## Global AI Agent Orchestration Master capstone

The capstone is intentionally rigorous. It requires all 17 domains to be current at Advanced, two distinct capstone missions completed within 12 months, at least three distinct agents, and two distinct named-human reviewers. At least one mission must be an authentic research and innovation leader task using permitted data; at least one must include an injected failure or degraded-capability scenario. A simulation cannot satisfy both. The capstone remains a workspace developmental award and carries none of the research-oversight, investigator-status, validation, authorization, data-access, participant-contact, deployment, or practice meanings excluded above.

The six capstone criteria require the candidate to:

1. frame two bounded, governed missions and apply EDENA, FRAME, TRACE, and PROBE as applicable;
2. design and execute least-privilege multi-agent orchestration;
3. pass the named safety, privacy, permission, failure, cost, cancellation, recovery, and cleanup tests;
4. contain an injected failure and safely transfer to a human-owned path;
5. produce a reviewed, accessible, provenance-rich artifact and portable evidence package; and
6. evaluate both missions and implement one measurable system improvement.

All frozen DISCOVER agents begin `PERM-P0 Disabled`. Each run needs a narrow ORBIT charter, explicit one-run permission, exact data/tool/destination limits, budget, expiry, human release, and verified return to P0. No agent may self-delegate, self-approve, inherit permission, expand its objective, hide persistence, suppress dissent, or claim that a real-world action occurred.

The capstone MUST NOT be awarded when a critical control is unavailable, a safety finding remains open, evidence contains prohibited data, a prerequisite has expired, a correction is unresolved, a reviewer is conflicted, or either reviewer has not approved. The capstone expires after 12 months. Renewal requires a new governed multi-agent mission, a fresh safety/recovery test run, one observed improvement, and approval by both required reviewer functions.

## Capabilities and Mastery page

### Overview

Show:

- the noncredential disclaimer;
- current criteria version and last recalculation time;
- 17 domain cards with current level, status, progress, earned/validation/renewal dates, and next challenge;
- a separate global capstone card;
- active correction, expiry, suspension, or revocation notices;
- portable export and review-queue controls; and
- a direct link to “How badges work.”

Do not use a single celebratory percentage as the main state. Show missing review and safety gates as prominently as criteria progress.

### Domain detail

For Basic, Intermediate, and Advanced, render each observable criterion from the JSON with:

- satisfied or unmet state;
- approved evidence count and evidence summaries;
- named reviewer and decision date;
- governance and safety evidence;
- expiry or correction notice;
- reason it does or does not count; and
- a button to submit evidence or request human review.

The application MAY use encouraging language, but it MUST not congratulate a user for an unreviewed click, starter, demo, or AI output.

### Evidence detail

Show metadata and a safe locator, not copied sensitive content. The detail view must expose provenance, criterion mappings, version history, integrity status, governance classification, reviewer disposition, limitations, correction state, and deletion controls.

### Reviewer view

Give the reviewer the exact criterion text, submitted evidence metadata and permitted artifacts, governance state, candidate attestation, prior relevant reviews, conflicts, and decision choices. Require deliberate confirmation. A reviewer cannot bulk-approve unseen criteria.

### Accessibility

Status, warnings, expiry, review state, and progress MUST be available as text, not color alone. All evidence and review controls must work with keyboard and assistive technology. Announce recalculation results, preserve focus, and provide a summary of affected awards after a correction or revocation.

## Portable export

Export `discover-capability-export+json` version `1.0.0`. Include the criteria version, pseudonymous candidate ID, current and historical status, criterion results, minimized evidence metadata and hashes, named-human review metadata, dates, progress, next challenges, governance/safety evidence, change history, disclaimer, and integrity manifest.

Exclude provider secrets, raw Soul Quiz answers, hidden agent context, PHI, personnel or credentialing records, prohibited payloads, and full artifact bodies unless the user separately selects them and policy permits them.

The receiving workspace MUST validate schema, hashes, dates, criteria version, reviewer attestations, state history, and data classification. Imported evidence remains untrusted until the receiving workspace validates it. Importing a badge never imports authority, licensure, certification, investigator status, IRB or HRPP approval, an exemption or regulatory determination, scientific validation, institutional approval, data access, participant-contact permission, intervention or deployment authority, or permission to run agents.

## Versioning and migration

Use semantic versioning:

- patch clarifies wording without changing the evidence burden;
- minor adds backward-compatible fields, evidence types, or optional criteria; and
- major changes required criteria, reviewer burden, level meaning, or capstone threshold.

Every award is pinned to `criteriaVersion`. Never silently reinterpret an historical award under a newer model. A migration records source and target version, mapping, affected awards, whether revalidation is required, named reviewer, date, and receipt. A major migration requires an explicit user-visible revalidation decision.

## Minimum verification tests

Hermes MUST implement and pass at least these tests:

1. JSON loads, has exactly 17 unique domain IDs, three levels per domain, three unique criteria per level, and six unique capstone criteria.
2. Every criterion references only declared eligible evidence types.
3. A click, tutorial, unadopted Starter, copied demo, AI attestation, self-review, duplicate, and prohibited-data record each fail admission.
4. Adopted Starter work does not count until materially completed, evaluated, and reviewed.
5. A synthetic safety test can support a test criterion but cannot satisfy the authentic capstone mission requirement.
6. Basic cannot become earned without all criteria, distinct evidence minimums, governance evidence, and one named-human approval.
7. Intermediate fails when Basic has expired; Advanced fails when Intermediate has expired.
8. Advanced rejects a reviewer who was the sole author, operator, or approver of the submitted work.
9. The capstone rejects 16 Advanced domains, one reviewer, two agents, two simulations, expired evidence, or an open safety finding.
10. The capstone passes only after all 17 Advanced domains, two qualifying missions, three agents, six criteria, and both reviewer functions are valid.
11. Evidence correction creates a new version and reopens review rather than modifying the reviewed record.
12. Evidence deletion, reviewer revocation, authority expiry, and governance reclassification each recalculate and cascade to dependent levels and the capstone.
13. Restoration requires new evidence/review and creates a receipt.
14. Expiry preserves history but removes the award from current totals and provides a renewal challenge.
15. Portable export contains the disclaimer, versions, minimized metadata, reviews, dates, progress, history, and hashes but no forbidden payload or secret.
16. An import with a bad hash, unknown criteria version, invalid review, unsafe data class, or cross-workspace reference fails closed.
17. Screen-reader and keyboard users receive the same status, evidence, warning, review, expiry, and correction information.
18. No UI, API, background job, import, migration, or AI response can set an award directly without the deterministic calculator and named-human decision.
19. Every required display and export surface shows the full noncredential disclaimer and rejects badge-derived claims of IRB/HRPP approval, investigator status, scientific or clinical validation, institutional authorization, data access, participant recruitment, intervention deployment, or permission to practice.
20. Role-specific review rejects a generic title-only qualification and requires a recorded qualification basis matched to the actual research or innovation activity being reviewed.

The capability feature is not release-ready if awards can be edited directly, reviews can be anonymous or AI-generated, evidence payloads leak into logs or exports, recalculation is incomplete, or the capstone can be earned through sample content.
