Evidence Credential Architecture

When “MASTERED” still does not mean “issue the badge”

A learner has a governed MASTERED state for one competency, backed by two independent transfer artifacts. An issuer wants to award a portable credential. One artifact contains sensitive internal context, and the credential-status service is not ready yet. If the platform simply turns MASTERED into a badge file, it collapses three different decisions: what the learner proved, whether an issuer is authorized to make a credential claim, and whether the resulting credential can be safely verified and managed over time.

This lesson builds Evidence Credential Issuance & Verification Contract v1. The contract keeps mastery evidence immutable, makes issuance a separately auditable decision, minimizes disclosure, and requires visible status and verification evidence before a portable credential is trusted.

Lesson boundary and learning routes

MKN-006 owns Evidence Credential Architecture. MKN-001 is a hard conceptual prerequisite and MKN-005 is a soft bridge. The adjacent outcomes remain separate: this lesson does not redesign diagnostic assessment and does not absorb search relevance.

Foundation learners use the seventeen-field map and one worked fixture. Repair learners isolate the first invalid field or state. Experienced learners must defend issuer authority, privacy, verification and revocation semantics without confusing a syntactically valid proof with a valid issuance decision. No real credential, identity wallet or learner record is changed in this lesson.

Mental model: mastery evidence → issuance decision → credential → verification/status

The core flow is:

competency + governed mastery evidence → issuance eligibility review → credential representation → proof/status → holder presentation → verifier result → status/update without rewriting mastery history

The mastery snapshot answers what learning evidence was accepted under a governed competency policy. The issuance decision answers whether an authorized issuer may make a portable claim from that snapshot. The credential representation carries the claim, subject, issuer, criteria and references. Verification checks the presented credential and its proof/status. Revocation or update changes credential state; it does not travel backward in time and erase the learning evidence that supported the original decision.

Foundation contract: seventeen auditable dimensions

The Contract records credential_id, credential_type, subject_id, issuer_id, and issuer_authority_ref for identity and authority. competency_id, criteria_ref, evidence_refs, and mastery_snapshot_ref bind the portable claim to governed learning evidence. issuance_decision_ref preserves the separate issuance decision.

issued_at and validity_or_review define lifecycle timing. credential_status_ref exposes status/revocation lookup. proof_or_verification_method and verification_result make technical verification visible. privacy_disclosure_state records whether evidence is disclosed directly or referenced with minimization. revocation_or_update_reason explains lifecycle changes.

A row with all seventeen fields is still not automatic approval. Values must be semantically valid and mutually consistent.

Deep explanation: FACT, INFERENCE, and DESIGN must stay separate

FACT — Open Badges. Current 1EdTech material describes Open Badges as verifiable achievements with defined metadata about the achievement, issuer and earner, including criteria and possible supporting evidence. Open Badges 3.0 aligns its model with Verifiable Credentials Data Model 2.0 conventions.

FACT — Verifiable Credentials. W3C VC Data Model 2.0 defines an issuer-holder-verifier ecosystem for machine-verifiable credentials and explicitly addresses security and privacy considerations. The model explains credential representation and exchange; it does not decide whether a learner has mastered a MAKNOW competency.

INFERENCE — verification is broader than proof syntax. A proof can be structurally valid while issuer authority, subject binding, status, criteria mapping or evidence sufficiency is wrong. Therefore a verifier result must reconcile multiple evidence dimensions rather than equating “signature verifies” with “credential claim is valid for this learning system.”

DESIGN — MAKNOW. Evidence sufficiency, mastery snapshot governance, issuance authorization, privacy disclosure, credential lifecycle and HOLD/REVIEW states are local design authority. External standards provide mechanisms, not permission to bypass those decisions.

Worked examples: baseline hold, invalid authority, privacy-preserving issuance, and transfer

Baseline — mastered, but status service is not ready. The learner has a valid mastery snapshot and two sufficient evidence references. Issuer authority is valid and the sensitive artifact is represented by a privacy-preserving reference. However the credential status endpoint is not configured and verification has not run. The bounded state is CREDENTIAL_ISSUANCE_HOLD_STATUS_VERIFICATION. Mastery remains MASTERED; only credential issuance waits.

Invalid shortcut — proof is syntactically valid but issuer authority is removed. The cryptographic-looking proof does not rescue the credential. The state is HOLD_ISSUER_AUTHORITY: authorship/proof syntax and authority to issue this competency claim are different questions.

Privacy-preserving ready case. The sensitive attachment itself is removed from the credential package, but an authorized evidence reference remains, evidence sufficiency is preserved, status is configured, and verification succeeds. The state can become CREDENTIAL_ISSUANCE_REVIEW_READY without over-disclosing the evidence body.

Transfer — second authorized issuer and different format. Reuse the governed mastery snapshot by reference, create a new credential identifier and new issuance-decision record, re-evaluate issuer authority, status and verification method, and do not duplicate or rewrite the underlying mastery evidence.

Failure modes that must fail closed

The decision remains HOLD when credential or subject identity is unknown, issuer authority is absent, competency and criteria do not match, evidence references are missing or unresolved, the mastery snapshot is absent, the issuance decision is missing, an issued credential lacks an issuance time, lifecycle/status reference is unknown, the verification method is unsupported, privacy state over-discloses protected evidence, verification fails, or a revoked credential lacks a revocation reason.

Two failures deserve special attention. First, revocation is not mastery rollback: changing the underlying mastery snapshot because a credential was revoked is a history mutation and must fail. Second, transfer is not copying: a second issuer or format requires a new mapping/issuance decision even when the same mastery snapshot is referenced.

Alternatives and trade-offs: embed, reference, status, and lifecycle

Embedding full evidence can make review easy but increases privacy exposure and portability risk. Referencing evidence minimizes disclosure but requires durable, authorized resolution and clear provenance. A static credential file is simple, yet it cannot by itself communicate later revocation or suspension; an explicit status mechanism adds operational dependency but makes lifecycle changes auditable.

A long validity period reduces renewal friction but increases the chance that stale claims remain active. Frequent review improves freshness but adds cost. A credential format with strong ecosystem support can improve portability, but format choice still cannot define mastery sufficiency. The Contract keeps these trade-offs visible instead of hiding them inside a badge template.

Experienced bridge: trust is a chain, not a signature boolean

For experienced engineers, treat credential trust as a chain of independently reviewable links: subject binding, issuer identity, issuer authority for the competency, criteria/evidence mapping, immutable mastery snapshot reference, issuance decision, credential status, proof verification, and disclosure policy.

Cryptographic verification answers a narrower question than educational validity. A perfectly verified credential can still be semantically wrong because it names the wrong competency, was issued by an unauthorized party, or presents stale/revoked status. Conversely, revoking the credential does not prove the learner “unlearned” the competency. Preserve those domains as separate state machines.

Guided and independent practice

1. Run the baseline and explain why mastery remains valid while credential issuance is held. 2. Remove issuer authority but keep proof syntax valid. 3. Replace the sensitive evidence attachment with a privacy-preserving reference and verify evidence sufficiency. 4. Mark the credential revoked while leaving the mastery snapshot unchanged. 5. Delete the revocation reason and observe the HOLD. 6. Change to a second authorized issuer and a different format; rebuild the issuance mapping without copying the baseline decision.

For independent practice, remove the expected state. The learner receives only the seventeen Contract dimensions, visible fixture facts and deterministic rules.

Verification evidence: what a reviewer must reproduce

A reviewer must reconstruct the subject, issuer and issuer authority; competency and criteria; evidence references and mastery snapshot; issuance decision; issuance/lifecycle timing; credential status; proof/verification method; privacy disclosure state; verification result; and any revoke/update reason. The reviewer must be able to show that no credential lifecycle action mutated the mastery history.

The deterministic lab covers baseline hold, fully ready issuance, missing issuer authority, subject and criteria mismatches, missing/unresolved evidence, missing mastery and issuance references, invalid lifecycle timing, status/proof/privacy/verification failures, revoked-without-reason, revoked-with-mastery-preserved, mastery-history mutation, privacy-preserving evidence reference, and transfer to a second issuer with and without a rebuilt mapping.

Assessment and transfer: same mastery, new issuer and credential format

The assessment has four blocking parts: explain MKN-006’s owned boundary and one non-goal; build the baseline Contract; diagnose the syntactically valid proof with missing issuer authority; and rebuild the transfer case for a second authorized issuer using a different credential format.

Transfer passes only when the governed mastery_snapshot_ref remains a reference to the same learning evidence, a new credential/issuance decision is created, issuer authority and status/verification semantics are re-evaluated, and no baseline decision is used as an oracle. If the second issuer is unauthorized, the correct outcome is HOLD even though the learning evidence did not change.

References, freshness, and authority boundary

Official 1EdTech Open Badges material and W3C Verifiable Credentials material were rechecked on 2026-09-13. 1EdTech currently describes Open Badges 3.0 as information-rich verifiable achievements with issuer/earner, criteria and possible evidence metadata, and its specification materials align the model with VC Data Model 2.0. W3C VC Data Model 2.0 remains a Recommendation; W3C also has a newer 2.1 Working Draft, so evolving credential semantics should be rechecked by 2027-01-15 or earlier on material change.

The standards are factual mechanism sources. MAKNOW retains design authority over mastery evidence sufficiency, issuance eligibility, privacy policy, credential lifecycle, review ownership and the rule that credential changes never rewrite mastery history.