The learning lifecycle FAQ

This FAQ unpacks the lifecycle story question by question, organized by the five audiences who carry the lifecycle — learners, authors, assessors, issuers, and verifiers. Each answer names the guardrail it rests on and links to the essay where it’s argued in full. Where the evidence is thin, the answers say so.

For learners

Q: Can I trust that earning this credential actually means I have the skill — not that I gamed an assessment?

A: We earn your trust by being honest about what assessment can and can’t do. Every item in a Mneurix credential is backed by an evidence trail — your actual responses, the council’s per-model verdicts, and the reasoning behind each score — so a credential means a panel of independent models converged on your competence, not that you survived a surveillance filter. We treat assessment validity, not proctoring theater, as the real security perimeter; if the assessment is weak, no amount of webcam-watching saves it. See assessment validity is the new security perimeter.

Q: If the AI council grades me wrong, can I appeal — and on what basis?

A: Yes, and the appeal isn’t a courtesy — it’s structural. Every assessment produces an appeal-grade audit trail: each model’s individual verdict, where the council agreed and disagreed, the conviction level behind the final call, and the evidence it relied on. If a grade feels wrong, you can see exactly which model broke from the consensus, what it flagged, and why; a human reviewer can then weigh that dissent as advisory. Contestability is what makes an automated grade legitimate, not a black-box decree. See the explainability gap.

Q: Is my credential portable, or am I locked to your platform or wallet?

A: Your credential belongs to you, not to us. We issue verifiable credentials using open standards (W3C VC + status lists), held in a wallet or store you control, and revocation status is published at a URL any verifier can poll — no account with us required. We chose sealed-key custody over a blockchain so portability doesn’t mean “portable as long as you’re on our chain”; it means a signed, inspectable artifact any compliant verifier can read. See the credentialing trust stack and why we didn’t use a blockchain.

Q: Will employers — or their agents — actually find and read my credential, or will it be ignored for a brand-proxy degree?

A: This is the question we lose sleep over, and the honest answer is: it depends on receiver legibility, which we’re actively building toward. Credentials issued through the Lattice satisfy a five-property protocol — discoverable, verifiable, machine-readable, status-fresh, and semantically parseable — so an employer’s agent can resolve your skill claims without a human intermediary. That makes you legible to the agentic web, not just to a recruiter who recognizes a university name. See credential discovery in the agentic web and verifiable credentials as protocol. We won’t claim every employer is ready today — but the infrastructure is built for the ones who will be.

Q: I’m neurodivergent. Will the assessment and materials work for me, or am I paying a bias tax — proctoring flags, inaccessible formats, materials that assume one cognitive style?

A: Traditional proctoring imposes a well-documented bias tax on neurodivergent learners: gaze-tracking flags stimming, timing penalizes different processing speeds, and surveillance itself raises anxiety that depresses performance without measuring skill. We don’t proctor that way — multi-model assessment evaluates your responses, not your face — and materials follow Universal Design for Learning, offering multiple representation and expression paths by default. Accommodation isn’t a separate workflow you request; it’s a baseline we build to, because an assessment that only works for one neurotype isn’t measuring ability, it’s filtering for conformity. See the proctoring bias tax and the accommodation tax is a myth.

Q: Is my work and data private and secure — who holds the signing key, and what’s logged about me?

A: Signing keys live in sealed custody — offline, access-controlled, and never exposed to the assessment pipeline — so the thing that attests your credential can’t be co-opted by the thing that grades you. What we log is scoped to what the audit trail needs: your responses, per-model verdicts, and council disagreement, retained long enough to support an appeal and no longer. We don’t sell data, we don’t train foundation models on your submissions, and your credential leaves with you in a format you control. See why we didn’t use a blockchain and the explainability gap.

For authors and instructors

Q: How do I make my materials verifiable — accurate, suitable, current — rather than just “trust me, I wrote it”?

A: Your materials are evidence, not assertion. Each item carries its own provenance: where the content came from (source citation), who checked it for accuracy and for suitability to the target population, what version it is, and when it was last reviewed for freshness. This is the provenance principle — the material itself must be inspectable, not just the author’s reputation. If a reviewer or an assessment-validity audit can’t reconstruct how your material was built and why it’s still sound, the credential downstream is unsupported. See assessment validity is the new security perimeter.

Q: Do I have to make materials accessible (UDL), and is that an accommodation tax on the default learner?

A: No tax — that’s the myth. Universal Design for Learning means offering options (multiple means of representation, expression, engagement), not replacing a default with a degraded version. Building accessible up front is cheaper and more honest than retrofitting later, and it doesn’t impose a cost on learners who don’t need the alternatives. The accommodation-tax framing assumes accessibility is a deduction from a baseline; in practice the baseline was never neutral to begin with. See the accommodation tax is a myth.

Q: What provenance do I need to capture so my materials actually feed a valid assessment?

A: At minimum: source attribution for factual claims, an accuracy-review record (who reviewed, when, against what standard), a version number or content hash, a freshness date with a defined review cadence, and a suitability attestation naming the learner population the material was validated against. The material is evidence the assessment rests on — if the chain is broken at any link, the verdict can’t be trusted. Capture it at authoring time, not reconstructed after the fact; retrospective provenance is mostly fiction. See assessment validity is the new security perimeter.

Q: How do I keep materials current and versioned without the credential going stale?

A: Treat freshness as a property of the material, not a one-time launch task. Each material item needs a defined review cadence (the freshness SLA) and a version that increments when content changes — so a credential issued against version 3.2 of a module can be checked against whether 3.2 is still the current, reviewed version. Stale materials rot the verdict downstream: a learner assessed against outdated content holds a credential whose evidentiary basis has quietly expired. The system doesn’t auto-magic this; you set the cadence, the platform tracks it, but the review itself is human work. See the credentialing trust stack.

Q: Who reviews whether my material is suitable for the learner population — including neurodivergent learners?

A: Suitability review is a distinct gate from accuracy review: accuracy asks “is this correct?”, suitability asks “is this the right material for these learners, given how they actually engage, process, and demonstrate knowledge?” That includes neurodivergent learners as part of the population, not as an edge case. Autistic self-advocates have named accessible learning as a precondition for participation — not a preference, not a bonus — which means suitability review that excludes them is reviewing the wrong population. Honest disclosure: we don’t yet have a standardized suitability-review protocol for neurodivergent populations across all subject domains, so this is an area where practice is still maturing and authors should err toward inclusion and consultation rather than assume a checklist exists. See what autistic people actually want researched.

For assessors and council operators

Q: How do I design a council that’s actually a measurement instrument, not a panel voting?

A: A council that majority-rules is a demo, not an instrument — measurement requires quorum thresholds, structured agreement metrics, conviction-weighting, and continuous drift monitoring, all logged per verdict. If you can’t point to the disagreement structure and say why the council converged, you’re running a poll. The instrument framing — treat the council like a calibrated sensor array, not a jury — is engineering reasoning from how we operate these systems day to day; it’s not a settled empirical literature with RCT backing, and I’d be dishonest to present it otherwise. See council design for assessment.

Q: My council members agree a lot — isn’t high agreement good?

A: High agreement across models that share training corpora is correlated agreement, and correlated agreement is a failure mode, not validity — when models inherit the same blind spots, they’ll agree confidently and wrongly together. Independence is what makes agreement meaningful: reward models that independently calibrate, not models that happen to converge. If your agreement metric can’t distinguish “they all got it right” from “they all copied the same mistake,” you don’t have a measurement, you have an echo. See council design for assessment.

Q: What must I log so a learner can actually appeal a verdict?

A: The audit trail needs to be appeal-grade: per-model verdicts, the disagreement structure (who diverged, where, on what signal), conviction levels, and a tamper-evident signed log that the learner (or a human reviewer) can inspect without taking your word for it. A verdict you can’t contest isn’t an assessment — it’s a decree. The bar is simple: could a reasonable reviewer reconstruct why the council said what it said from the log alone, without asking you? See the explainability gap.

Q: Where does human review fit — does it override the council?

A: Human review sits above the council as the appeal authority, not as a blocker in the hot path — the council produces the verdict; a human adjudicates when that verdict is contested. But review only functions if the council logged enough to review: without the per-model breakdown, the disagreement structure, and the conviction signals, the human reviewer is staring at a single number and rubber-stamping it. The human doesn’t rescue a council that didn’t log; they inherit its opacity. See why human review is advisory, not a blocker.

Q: How do I avoid the proctoring bias tax — I don’t want to flag neurodivergent learners for atypical gaze, stimming, or movement patterns?

A: The answer isn’t better proctoring calibration; it’s moving the security perimeter to assessment validity — evidence-first work product, not surveillance-first behavior policing. Proctoring is both bypassable (determined cheaters route around it) and biased (it systematically flags neurodivergent learners, non-native speakers, and learners with atypical motor patterns as suspicious). Every false flag is a tax on learners who were never cheating, and the tax falls hardest on the people your assessment is supposed to be fair to. See assessment validity is the new security perimeter and the proctoring bias tax.

Q: I’m using closed-weight models — what about silent vendor updates changing my council’s behavior?

A: Closed-model drift is a reproducibility threat you can’t eliminate, only contain: version-pin the exact model identifier per verdict so every logged assessment points at the model that actually produced it, and drift-monitor a golden set — a stable benchmark suite the council scores repeatedly — so you catch behavioral shifts before they contaminate live verdicts. If your vendor silently updates a model and you can’t tell, your council’s calibration history is fiction. Pin the versions; watch the golden set; treat any unexplained delta as a signal, not noise. See council design for assessment.

For issuers and governance

Q: Why sealed-key custody and not a blockchain — isn’t a chain more trustless?

A: A blockchain solves tamper-evidence — proving a credential hasn’t been altered after issuance — and that problem is essentially solved. What it doesn’t solve, and what actually carries the trust, is issuer identity: who held the key, who controls it now, and whether the entity signing is the entity you think it is. Sealed-key custody is the trust anchor because it binds signing authority to a physical custody chain with rotation as a governed event. The chain is an excellent ledger; it is a poor custodian. See why we didn’t use a blockchain.

Q: How do I handle revocation so a verifier can trust the credential is still valid right now?

A: A signed credential encodes a claim at a point in time; it says nothing about the present without a live signal. You need a revocation endpoint that verifiers can poll, backed by a freshness SLA — e.g., revocation status is guaranteed current within N hours, and the endpoint’s own liveness is monitored. Stale revocation is worse than no revocation: it gives a verifier false confidence that they checked, when what they actually saw was a cached lie. See the credentialing trust stack.

Q: Is the council that issues the verdict a governed institution or just a model demo? Why does that matter for the signature?

A: The council is the new registrar — a governed body with recorded rules, per-model verdicts, dissent preserved on the record, an appeal path, and versioned precedent. That governance is what makes the signature meaningful: a key under custody signs on behalf of an institution, and the institution’s governance is what gives the signature its authority. A council with no governance records is a demo; a council with governance but no key custody is a paper institution. Both halves have to hold. See multi-model councils as governance.

Q: What happens to already-issued credentials if I have to rotate the signing key?

A: Rotation breaks already-issued credentials — by design. Verifiers stop trusting signatures from the old key, and every credential signed under it must either be reissued or explicitly bridged through a trust path the verifier can follow. This is uncomfortable, but it’s the point: key rotation is a trust event with a blast radius, not a dev-ops task you schedule for a maintenance window. If rotation were seamless, a compromised key would be indistinguishable from a rotated one, and you’d have lost the audit trail entirely. See the custodian problem.

Q: How is the issuer auditable from the outside — what does a verifier have the right to demand to see?

A: A verifier has the right to demand the appeal-grade audit trail: per-model verdicts, the dissent structure, the conviction level, the governing rules in force at issuance, and any appeals filed against the verdict. If the issuer can’t produce that, the credential is a fiat — an assertion with no traceable provenance. We don’t ask verifiers to trust the model; we ask them to inspect the record and decide whether the institution’s process was sound. An unauditable issuer is, structurally, a claim that governance is none of the verifier’s business. See the explainability gap.

Q: What’s the Blockcerts lesson — what failure are we specifically avoiding?

A: The Blockcerts-era failure mode is this: an attacker acquires or reuses an issuer-key mapping on-chain, mints credentials indistinguishable from genuine ones, and the blockchain records every forged credential faithfully and immutably. The chain does its job — tamper-evidence, ordering, timestamping — and the credentials are still forged. That’s a custody failure dressed as a consensus success, and it’s the specific reason we treat key custody as the hard problem rather than delegating trust to a ledger that was never asked to authenticate its signers. See why we didn’t use a blockchain.

For verifiers and employers

Q: Why should I resolve your credential instead of just trusting the university brand — what’s in it for me?

A: The honest answer is that today, resolving a credential’s richness costs you time and effort, but most of the value accrues to the learner and the issuer — that’s the incentive asymmetry that kills adoption at the receiver checkpoint, and we won’t pretend otherwise. The only way this works for you is if verification cost drops to effectively zero: a single resolver call that returns the signed credential, revocation status, evidence, and semantic mapping without you building anything new. Until that’s true, trusting the brand is rational. We’re building the resolver to make it true; we’re not asking you to eat the cost. See verifiable credentials as protocol and why micro-credentials die at the employer checkpoint.

Q: A learner shows me twelve micro-credentials. Am I supposed to compose those into a skill picture myself?

A: No — that’s exactly the receiver-side re-bundling problem, and if we left it to you, you’d rightly ignore the whole stack. The Lattice issues atoms, but a receiver-side layer composes them into a legible whole at query time, mapped to your role’s competency frame, so you get one resolved picture rather than twelve puzzle pieces. The composition cost belongs on our side of the table, not yours. See why micro-credentials die at the employer checkpoint.

Q: Can my hiring/procurement agent resolve these credentials automatically?

A: Yes, provided the credential is agent-legible — a resolvable issuer DID, a signed VC, a live revocation endpoint, evidence pointers, and machine-readable semantics for the competency claim. If any of those are missing, the credential is invisible to an agent, which in the agentic web means it’s effectively invisible to your pipeline. We treat agent-legibility as a first-class spec requirement, not a nice-to-have. See credential discovery in the agentic web.

Q: How do I detect a forged credential — won’t people just fake these like they fake resumes?

A: A signed VC plus a live revocation check gives you cryptographic fraud detection for free: a forged credential fails the signature or revocation lookup, full stop. The current system fails here because a forged brand-proxy (a diploma-mill name that looks like a real university) is invisible to you — there’s no cryptographic anchor, so you’re left sniffing the PDF. VCs close that gap: the signature either verifies against the issuer’s DID or it doesn’t. See verifiable credentials as protocol.

Q: If a credential is wrong and the learner appeals, do I get to see the council’s dissent and reasoning — or just a score?

A: You get the audit trail — per-model verdicts, disagreement across the evaluating council, and conviction levels — not just a final number. This matters because a single score with no reviewable provenance is an unverifiable claim about an unverifiable claim, which is worse than the resume you’re trying to replace. The appeal-grade audit trail makes the verdict inspectable by both sides; if you’re evaluating a contested credential, you can see the reasoning, not just the outcome. See the explainability gap.

Q: What’s this going to cost me to integrate — is this another ATS replacement project?

A: No. The resolver is a receiver-side verification API that slots behind your existing intake as a single call — pass it a credential reference, get back the resolved, composed, revocation-checked result. You’re not replacing your ATS or your procurement system; you’re adding one resolver call to the step where you currently eyeball a PDF. The design principle is: build the receiver, not a new system. See verifiable credentials as protocol.

---

We’re aware the evidence for employer-side adoption is thin — much of this FAQ is a design thesis, not a deployed track record. The claims about cryptographic fraud detection and resolver-cost-to-zero are grounded in the protocol spec; the claims about receiver-side re-bundling and agent-legibility are what we’re building, and we’d rather say that plainly than oversell it. If you’re a verifier and the above doesn’t match your reality, that’s useful to us — tell us where it breaks.