# X. LEARNING

## 10.1 Learning Object Doctrine

### 10.1.1 Learning object defined.

A **Learning Object** under the Distributed Digital Public Goods Framework means any governed digital-public-good object designed to support knowledge transfer, skill formation, competency development, risk literacy, technical literacy, public-good contribution, public authority learning, Academy delivery, Risk Academy delivery, Foundry preparation, Studio practice, Nexus Universe preparation, National Portfolio capability formation, or lawful handoff literacy. Learning Objects may include courses, modules, units, lessons, labs, simulations, Studio exercises, open textbooks, public-safe guides, instructor packs, micro-credentials, badges, capstones, work-integrated learning objects, contribution tasks, assessment objects, scenario objects, and knowledge products.

A Learning Object shall be treated as a lifecycle-governed digital object, not merely educational content. It shall have a recorded purpose, audience, scope, competency mapping, evidence basis where applicable, source class, review status, accessibility status, localization status, public-safe status, data-use label, AI-use label where applicable, license class, support class, steward, version, correction pathway, archive rule, and boundary notices. A Learning Object may support learning, contribution, competence formation, and public-good participation, but shall not create professional certification, employment eligibility, public authority approval, procurement qualification, deployment authorization, financeability, insurability, community or Indigenous consent, or execution authority by implication.

### 10.1.2 OER object defined.

An **Open Educational Resource Object** means a Learning Object made available under an approved open, public-good, or controlled-open license that permits reuse, adaptation, translation, localization, redistribution, or derivative learning use within the limits of its license, sensitivity class, source rights, public-safe status, and safeguard controls. OER Objects may include open courses, modules, lessons, open textbooks, guides, slide decks, exercises, assessment rubrics, lab manuals, facilitator packs, scenario packs, and public-safe training materials.

An OER Object shall be open only to the extent recorded. Open access shall not override data rights, protected knowledge controls, community safeguards, Indigenous protocols where applicable, privacy obligations, cyber-sensitive restrictions, public authority-sensitive restrictions, licensing restrictions, attribution duties, or correction obligations. OER use shall not imply endorsement, certification, professional qualification, procurement eligibility, public authority approval, or deployment authorization.

### 10.1.3 MOOC object defined.

A **MOOC Object** means a structured, digital, cohort-based, self-paced, instructor-led, blended, or open-enrollment learning pathway designed for broad participation through Nexus Academy, Risk Academy, National Nodes, partners, universities, technical institutes, public authority learning environments, or other approved distribution channels. MOOC Objects may include video lessons, readings, quizzes, labs, simulations, Studio exercises, discussion prompts, peer-review tasks, capstones, public-safe assignments, competency mappings, micro-credential pathways, and ILA-linked completion records.

A MOOC Object shall not be treated as a degree, license, public authority credential, professional certification, employment guarantee, immigration credential, procurement qualification, or regulatory approval unless a separate competent authority or authorized credentialing body expressly records such status outside the default DDPGF posture. MOOC completion may generate learning records, participation records, competency evidence, micro-credential eligibility, or ILA entries only within recorded scope.

### 10.1.4 Open textbook object defined.

An **Open Textbook Object** means a governed, openly reusable, public-good instructional or reference publication designed to support structured learning, technical literacy, public-safe knowledge, risk literacy, workforce development, Academy delivery, Risk Academy delivery, Foundry preparation, National Portfolio capacity, or Nexus Universe preparation. Open Textbook Objects may include chapters, figures, case studies, datasets where permitted, exercises, glossaries, assessment prompts, instructor resources, translation layers, accessibility files, and repository metadata.

An Open Textbook Object shall include version control, authorship or stewardship records, source notes, license terms, accessibility review, public-safe review, citation guidance, correction pathway, withdrawal pathway, archive rule, and localization controls. Open textbook publication shall not create official doctrine, public authority decision, certification, legal advice, professional advice, finance advice, medical advice, procurement advice, or operational instruction unless separately and lawfully recorded.

### 10.1.5 Learning pathway object defined.

A **Learning Pathway Object** means a sequenced, competency-mapped, role-aware, domain-aware, and evidence-bearing arrangement of Learning Objects designed to move a learner, contributor, reviewer, maintainer, mentor, public authority learning participant, National Working Group participant, Competence Cell member, Foundry contributor, Campaign participant, Studio user, or handoff-context actor through a defined learning journey. Learning Pathway Objects may be introductory, technical, domain-specific, cross-domain, national, regional, global, public authority learning-oriented, workforce-transition-oriented, WILP-linked, micro-credential-linked, Foundry-linked, Studio-linked, Grid-linked, TRL-linked, Nexus Universe-linked, or handoff-literacy-oriented.

A Learning Pathway Object shall define prerequisites, intended audience, competency targets, learning outcomes, estimated effort, practice objects, assessment objects, evidence outputs, public-safe outputs, accessibility status, language status, review level, completion records, correction pathways, renewal conditions, and archive rules. Completion of a pathway shall not imply professional licensing, employment, procurement eligibility, public authority approval, deployment authorization, or execution authority unless separately recorded by a competent authority outside the default DDPGF framework.

### 10.1.6 Credential object defined.

A **Credential Object** means a bounded digital record of learning, competency evidence, assessment completion, contribution evidence, practice completion, review capability, maintainer capability, pathway completion, WILP completion, or public-good participation issued within a recorded scope. Credential Objects may include micro-credentials, badges, certificates of completion, evidence records, competency records, reviewer records, maintainer records, public-safe reporting credentials, Foundry contribution records, Studio practice records, Risk Academy literacy records, and ILA-linked records.

A Credential Object shall include credential scope, issuer identity, evidence basis, assessment method, review level, validity period, expiry, renewal conditions, suspension conditions, withdrawal conditions, correction history, Registry status, display rules, privacy controls, portability rules, and boundary notices. A Credential Object shall not be a professional license, degree, employment guarantee, procurement qualification, public authority approval, deployment authorization, financeability signal, insurability signal, or execution authorization by default.

### 10.1.7 Knowledge product as reusable public good.

A **Knowledge Product** means a reusable, governed digital-public-good object that translates evidence, methods, records, research, practice, lessons, risks, safeguards, workflows, standards-interface notes, software guidance, data guidance, AI-use guidance, public-safe reporting guidance, or handoff literacy into accessible, reviewable, correctable, and reusable form. Knowledge Products may include plain-language summaries, expert summaries, technical guides, community guides, public authority learning guides, contributor guides, developer guides, maintainer guides, handoff literacy guides, FAQs, checklists, visual explainers, decision-support notes, learning briefs, and public-safe briefings.

Knowledge Products shall preserve source traceability, scope boundaries, public-safe language, sensitivity controls, role-separation notices, correction pathways, archive rules, and reuse terms. A Knowledge Product may support learning and interpretation, but shall not substitute for professional advice, public authority decision-making, regulatory compliance, procurement diligence, financial advice, insurance underwriting, legal authorization, community consent, Indigenous consent where applicable, deployment approval, or execution authority.

### 10.1.8 Learning without certification by implication.

Learning under DDPGF shall create learning records, competency evidence, contribution memory, public-good capability, pathway progress, ILA entries, iCRS-linked recognition where applicable, and Registry-visible status where authorized. Learning shall not create certification, licensing, employment, procurement, public authority approval, financeability, insurability, deployment authorization, public warning authority, professional standing, or execution authority by implication.

The default rule shall be **evidence before credential claims, records before recognition, review before display, correction before trust, and separate authority before any regulated meaning**. Where learning objects interface with universities, credential authorities, professional bodies, public authorities, employers, donors, insurers, capital readers, National Consortium Companies, Project SPVs, or other lawful downstream actors, the learning record shall remain bounded unless a separate competent authority expressly adopts, recognizes, validates, or relies upon it through its own lawful process.

## 10.2 Learning Object Classes

### 10.2.1 Courses.

A **Course Object** means a structured learning object composed of modules, units, lessons, activities, assessments, readings, exercises, labs, scenarios, simulations, Studio workflows, public-safe outputs, and completion records. Course Objects may be introductory, advanced, technical, domain-specific, cross-domain, public authority learning-oriented, workforce-transition-oriented, Foundry-oriented, Campaign-oriented, Studio-oriented, Grid-oriented, TRL-oriented, National Portfolio-oriented, or handoff-literacy-oriented.

A Course Object shall include course identity, purpose, audience, prerequisites, competency map, learning outcomes, syllabus, release class, license class, assessment method, accessibility status, language status, public-safe status, review status, support class, correction pathway, and archive rule.

### 10.2.2 Modules.

A **Module Object** means a coherent subdivision of a Course Object or Learning Pathway Object focused on a defined competency, concept, practice, tool, method, domain, safeguard, workflow, or output. Module Objects shall be reusable across courses, pathways, MOOCs, WILPs, Risk Academy tracks, Nexus Academy tracks, Foundry onboarding, Studio practice, Campaign onboarding, and Nexus Universe preparation where scope permits.

A Module Object shall identify dependency relationships, required prior knowledge, estimated effort, evidence outputs, assessment requirements, public-safe restrictions, and localization requirements.

### 10.2.3 Units.

A **Unit Object** means a smaller instructional segment within a Module Object, designed to teach or practice a specific concept, skill, procedure, boundary, method, or applied task. Unit Objects may be used independently where approved or embedded in courses, pathways, OER packages, MOOCs, open textbooks, WILPs, Studio exercises, or public-safe guides.

A Unit Object shall preserve source notes, learning outcomes, review status, accessibility status, and correction linkage to its parent module or pathway.

### 10.2.4 Lessons.

A **Lesson Object** means a discrete teaching object that presents a specific learning point, method, example, doctrine, workflow, scenario, technology, safeguard, boundary rule, or practice activity. Lesson Objects may include text, video, audio, diagrams, code snippets, notebooks, quizzes, exercises, reflection prompts, and public-safe examples.

Lesson Objects shall be designed for clarity, accessibility, localization, correctionability, and reuse. A Lesson Object shall not convert instructional explanation into official advice, public authority instruction, technical certification, legal determination, or execution authorization.

### 10.2.5 Labs.

A **Lab Object** means a practice-oriented learning object that allows learners or contributors to apply skills through controlled exercises, data tasks, coding tasks, analysis tasks, simulation tasks, dashboard tasks, DRI tasks, GRIx mapping tasks, Studio workflows, cyber exercises, AI evaluation exercises, public-safe reporting tasks, or Foundry build preparation. Lab Objects may use synthetic data, public-safe data, controlled data, notebooks, APIs, sandbox environments, secure rooms, or Studio environments.

Lab Objects shall include safety controls, data-use labels, AI-use labels, tool permissions, expected outputs, review criteria, public-safe limits, and correction pathways. Lab completion shall not authorize real-world deployment or operational use.

### 10.2.6 Scenarios.

A **Scenario Learning Object** means a narrative, analytical, simulation-linked, tabletop, or Studio-linked learning object that presents a possible situation, hazard, system stress, technology issue, governance challenge, WFEH-B cascade, disaster-risk pathway, AI incident, cyber-physical event, public authority learning question, finance-readiness question, safeguard issue, or handoff dependency for structured learning.

Scenario Learning Objects shall include assumptions, uncertainty, confidence labels where applicable, scope boundaries, public-safe interpretation notes, and no-warning notices. A scenario is not a forecast, public warning, official prediction, or operational instruction.

### 10.2.7 Simulations.

A **Simulation Learning Object** means a computational, conceptual, tabletop, Studio-based, digital twin-linked, model-based, or scenario-based exercise that allows learners to explore system behavior, interventions, constraints, uncertainties, dependencies, and consequences within a defined learning scope. Simulation Learning Objects may support Risk Academy, Nexus Academy, public authority learning, Foundry training, Studio practice, DRI literacy, Observatory literacy, Grid literacy, TRL literacy, and handoff literacy.

Simulation Learning Objects shall be bounded by assumptions, limitations, data basis, model basis, uncertainty, review status, and public-safe restrictions. Simulation results shall not be presented as certification, forecast certainty, public authority decision, finance signal, procurement signal, deployment authorization, or execution authority.

### 10.2.8 Studio exercises.

A **Studio Exercise Object** means a controlled learning workflow within Nexus Studio or a Studio-equivalent environment that allows learners, contributors, public authority learning participants, reviewers, maintainers, or handoff-context actors to practice with dashboards, data rooms, secure rooms, digital twins, AI workflows, simulations, scenario workflows, Registry objects, Marketplace objects, Grid inputs, TRL notes, or handoff packages.

Studio Exercise Objects shall apply role-based permissions, no-command rules, no-write-back rules, output review, logging, data export restrictions, public-safe restrictions, shutdown triggers, and archive rules. Studio exercises shall not authorize deployment or operational command.

### 10.2.9 Work-integrated learning objects.

A **Work-Integrated Learning Object** means a learning object connected to a supervised practice environment, host environment, contribution pathway, WILP, apprenticeship-style pathway, internship-style pathway, practicum, field exercise, Foundry contribution, Campaign contribution, Studio practice, National Working Group practice, or Competence Cell practice. It shall convert learning into evidence-bearing practice while preserving labor, data, safeguard, and boundary controls.

Work-Integrated Learning Objects shall define host role, mentor role, learner role, workplan, scope, supervision level, evidence outputs, labor boundary, health and safety controls, confidentiality controls, data-use rules, AI-use rules, grievance channels, correction channels, and archive rules. Participation shall not create employment, compensation, procurement qualification, deployment authority, or execution authority by implication.

### 10.2.10 Micro-credentials.

A **Micro-Credential Object** means a bounded credential object recognizing completion, competence evidence, assessment, contribution, review capability, maintainer capability, public-safe reporting literacy, risk literacy, technical skill, WILP evidence, or Foundry output within a defined scope. Micro-credentials may be stackable, pathway-linked, ILA-linked, Registry-linked, Marketplace-display-eligible, or portfolio-display-eligible.

A Micro-Credential Object shall include issuer identity, evidence basis, assessment method, review status, expiry, renewal, suspension, withdrawal, correction pathway, and boundary notices. It shall not be a professional license, degree, public authority credential, employment guarantee, procurement qualification, deployment approval, or execution authorization by default.

### 10.2.11 Badges.

A **Badge Object** means a display object representing bounded achievement, participation, contribution, pathway progress, course completion, review role, maintainer role, mentor role, public-safe output, Foundry contribution, Campaign contribution, Studio exercise completion, or Nexus Universe participation. Badge Objects may be public, controlled, private, portfolio-linked, ILA-linked, Registry-linked, or Marketplace-display-eligible.

A Badge Object shall identify what it represents and what it does not represent. Badge display shall not imply employment eligibility, professional certification, licensing, public authority approval, procurement qualification, financeability, deployment authorization, or endorsement.

### 10.2.12 Capstones.

A **Capstone Object** means an integrative learning and contribution object that requires learners or contributors to produce a substantial evidence-bearing output, such as a public-safe Report, dataset, model card, system card, dashboard, software contribution, Studio workflow, National Portfolio contribution, DRI interpretation, GRIx mapping, WFEH-B analysis, risk scenario, public authority learning brief, Foundry build, Campaign object, or handoff literacy package.

A Capstone Object shall include scope, evidence requirements, review criteria, public-safe requirements, data and AI controls, safeguard controls, assessment method, correction pathway, and archive rule. Capstone completion shall not create deployment authorization, procurement qualification, employment claim, public authority approval, or execution authority.

### 10.2.13 Open textbooks.

An **Open Textbook Object** may be issued as a complete textbook, chapter series, modular textbook, technical manual, Academy reference, Risk Academy reference, public-safe guidebook, field guide, instructor resource, or translated/localized edition. It shall be governed as both a publication object and a learning object.

Open textbooks shall maintain versioning, source notes, authorship or stewardship records, license class, accessibility files, translation records, review status, correction notices, withdrawal pathways, and archive labels.

### 10.2.14 Public-safe guides.

A **Public-Safe Guide Object** means a knowledge product designed to explain complex, sensitive, technical, legal-boundary, public authority, finance-readiness, disaster-risk, AI, data, cyber, privacy, safeguard, protected knowledge, or handoff concepts in language suitable for approved audiences without creating overclaim, false authority, unsafe instruction, or unauthorized reliance.

Public-safe guides shall include audience definition, scope limits, boundary notices, sensitive knowledge exclusions, source notes, correction pathways, and accessibility review. A public-safe guide shall not be treated as legal, financial, medical, emergency, regulatory, procurement, or operational advice by default.

### 10.2.15 Instructor packs.

An **Instructor Pack Object** means a governed set of teaching materials for facilitators, instructors, mentors, faculty, trainers, public authority learning facilitators, Studio facilitators, Foundry mentors, Campaign trainers, or WILP supervisors. It may include lesson plans, slides, exercises, rubrics, answer guides, discussion prompts, accessibility notes, risk notes, safeguard notes, public-safe scripts, assessment guidance, and correction guidance.

Instructor Packs may be public, controlled, internal, secure-room-only, or host-restricted depending on sensitivity. Instructor access shall not create credentialing authority, assessment authority, public authority status, or employment authority unless separately recorded.

## 10.3 Learning Object Lifecycle

### 10.3.1 Intake.

Learning Object intake shall record purpose, audience, need, domain, competency target, source pathway, steward, sponsoring or contributing actors where applicable, language needs, accessibility needs, public-safe requirements, data-use requirements, AI-use requirements, safeguard requirements, national localization needs, and lifecycle expectations. Intake may originate from Nexus Academy, Risk Academy, Foundry, Campaigns, Labs, Reports, National Nodes, National Working Groups, Competence Cells, Risk Agency, Nexus Universe, Registry gaps, Marketplace demand, DRI gaps, GRIx gaps, DICE gaps, Studio needs, Grid needs, TRL needs, or handoff dependency needs.

Intake shall classify whether the object is public, controlled, restricted, secure-room-only, public authority learning-oriented, WILP-linked, micro-credential-linked, or handoff-literacy-oriented.

### 10.3.2 Competency mapping.

Each Learning Object shall be mapped to competencies, learning outcomes, skill levels, practice expectations, domain clusters, pathway relationships, and evidence requirements where applicable. Competency mapping may connect to SCF, Nexus Academy pathways, Risk Academy pathways, ILA records, WILPs, micro-credentials, iCRS records, Foundry quests, Studio exercises, Grid inputs, TRL notes, National Portfolio needs, and handoff literacy requirements.

Competency mapping shall not imply equivalence to professional standards, legal qualifications, licensing requirements, public authority criteria, employer qualifications, procurement qualifications, or international credential equivalence unless separately reviewed and recorded.

### 10.3.3 Content creation.

Learning Object content creation shall use approved sources, recorded authorship or stewardship, public-safe drafting rules, accessibility-by-design, localization readiness, evidence traceability, appropriate licensing, and boundary notices. Content may include text, visuals, code, notebooks, datasets, simulations, quizzes, videos, audio, diagrams, templates, case studies, scenario objects, Studio workflows, and assessments.

Content creation shall avoid unsupported claims, unsafe instruction, protected knowledge disclosure, sensitive data exposure, regulatory overclaim, finance overclaim, procurement overclaim, certification overclaim, public authority overclaim, endorsement overclaim, and execution overclaim.

### 10.3.4 Review.

Learning Objects shall be reviewed according to subject matter, audience, sensitivity, release class, credential relevance, public-safe status, and downstream use. Review may include technical review, pedagogy review, competency review, public-safe review, accessibility review, localization review, data review, AI-use review, cyber review, privacy review, safeguard review, protected knowledge review, public authority boundary review, finance boundary review, procurement boundary review, and handoff boundary review.

Review shall be recorded. Review completion shall not create certification, licensing, public authority approval, procurement status, financeability, insurability, deployment authorization, or execution authority by implication.

### 10.3.5 Accessibility check.

Learning Objects shall undergo accessibility checks appropriate to their release class and audience. Accessibility checks may address screen-reader compatibility, alt text, captions, transcripts, keyboard navigation, plain-language alternatives, color contrast, non-color-dependent meaning, mobile access, low-bandwidth access, downloadable formats, multilingual access, cognitive accessibility, disability inclusion, and reasonable accommodation pathways.

Accessibility status shall be recorded and corrected where necessary. A Learning Object that cannot meet required accessibility thresholds shall be restricted, revised, supplemented with alternatives, or labeled with limitations.

### 10.3.6 Translation.

Translation shall preserve substantive meaning, boundary notices, public-safe limitations, technical terminology, competency mapping, legal-context warnings, cultural context, and localization notes. Translation may include direct translation, adaptation, plain-language transformation, national localization, regional localization, terminology mapping, and accessibility adaptation.

A translated Learning Object shall identify source version, translation steward, review status, localization scope, unresolved terminology issues, and correction pathway. Translation shall not create legal equivalence, public authority adoption, national endorsement, credential equivalence, or community consent by implication.

### 10.3.7 Publication.

Publication may occur through Nexus Academy, Risk Academy, Nexus Reports, repositories, Marketplace, Registry, National Nodes, partner platforms, public-safe knowledge bases, open textbook repositories, MOOC platforms, Studio environments, or controlled rooms. Publication shall follow release class, license class, public-safe status, support status, accessibility status, and sensitivity controls.

Publication shall not convert the object into official advice, public authority decision, certification, procurement qualification, finance signal, insurance signal, deployment authorization, or execution authority.

### 10.3.8 Academy routing.

Learning Objects may be routed to Nexus Academy, Risk Academy, National Academy pathways, WILP pathways, Foundry onboarding, Studio practice, Campaign onboarding, Risk Agency training, National Portfolio preparation, Nexus Universe preparation, or handoff literacy tracks. Routing shall identify audience, prerequisites, delivery mode, review status, credential relevance, ILA linkage, and support class.

Academy routing shall not create credential status unless separately recorded through Credential Object Governance.

### 10.3.9 Marketplace listing.

Learning Objects may be listed in Nexus Marketplace for discovery, reuse, translation, contribution, support, sponsorship, hosting, cohort formation, instructor adoption, or pathway integration. Marketplace listing shall include metadata, license class, support class, public-safe status, accessibility status, language status, review status, Registry link, and boundary notices.

Marketplace listing shall not imply endorsement, procurement recommendation, employer recognition, public authority approval, certification, financeability, insurability, or deployment authorization.

### 10.3.10 Registry record.

Learning Objects shall receive Registry records where they are part of the official DDPGF object universe, Academy pathways, Risk Academy pathways, credential pathways, WILPs, Foundry work, National Portfolio capability formation, Nexus Universe outputs, or handoff literacy. Registry records shall preserve status truth, version, steward, review status, support status, public-safe status, correction history, withdrawal status, archive status, and display rules.

Registry status shall not create certification, licensing, public authority approval, employment eligibility, procurement qualification, or execution authority by implication.

### 10.3.11 Learner feedback.

Learner feedback shall be collected where appropriate to assess clarity, accessibility, relevance, usability, difficulty, inclusiveness, technical accuracy, public-safe quality, translation quality, practice value, and correction needs. Feedback may inform revision, correction, localization, support improvements, pathway redesign, and archive decisions.

Learner feedback shall be privacy-preserving and shall not be used for unauthorized learner ranking, social scoring, employment screening, public authority profiling, or commercial exploitation. Feedback shall not override subject-matter review or public-safe controls.

### 10.3.12 Correction.

Learning Objects shall remain correctionable throughout their lifecycle. Corrections may address factual errors, outdated content, unsafe language, inaccessible format, mistranslation, broken links, licensing errors, data errors, AI-use errors, public-safe overclaims, credential overclaims, public authority overclaims, finance overclaims, procurement overclaims, protected knowledge exposure, or safeguard failures.

Corrections shall be recorded, versioned, propagated to dependent objects, and communicated to affected learners, instructors, pathways, Registry records, Marketplace listings, credential objects, Reports, Studio workflows, and archived versions where necessary.

### 10.3.13 Retirement.

A Learning Object may be retired when it is outdated, superseded, unsupported, unsafe, redundant, no longer aligned with competency mapping, no longer public-safe, no longer accessible, no longer licensable, affected by source withdrawal, affected by correction burden, replaced by a successor object, or no longer fit for purpose. Retirement shall include status change, notice, successor link where applicable, affected-pathway review, credential impact review, and archive routing.

Retirement shall not erase records required for audit, learner history, credential history, correction history, or institutional memory unless lawful deletion is required.

### 10.3.14 Archive.

Archived Learning Objects shall preserve object identity, version, source notes, review history, public-safe status, license class, support status, correction history, retirement reason, successor link where applicable, access class, retention rule, and archive notice. Archived objects shall be marked as not-current, superseded, withdrawn, unsupported, deprecated, non-continuing, or historical, as applicable.

Archived Learning Objects shall not be used as current learning content, credential basis, public authority learning material, technical guidance, or handoff literacy unless separately reinstated or clearly labeled for historical reference.

## 10.4 Credential Object Governance

### 10.4.1 Credential scope.

Credential scope shall define the exact competence, learning outcome, pathway, contribution, assessment, practice, review capability, maintainer capability, or literacy area represented by the Credential Object. Scope shall identify whether the credential relates to awareness, literacy, applied practice, supervised contribution, independent contribution, reviewer capability, maintainer capability, mentor capability, public-safe reporting, Foundry contribution, Studio practice, WILP completion, Risk Academy learning, Nexus Academy learning, or handoff literacy.

Credential scope shall be bounded. It shall not imply broader competence, professional licensing, employment suitability, public authority approval, procurement qualification, financeability, insurability, deployment authorization, or execution authority.

### 10.4.2 Evidence basis.

Each Credential Object shall identify its evidence basis, including course completion, assessment results, portfolio artifacts, work products, peer review, mentor verification, host verification, public-good contribution, Studio output, simulation output, capstone output, WILP evidence, Foundry evidence, public-safe output, correction evidence, or renewal evidence. Evidence basis shall be accessible according to privacy, public-safe, data, and display controls.

A credential without sufficient evidence basis shall not be issued, or shall be clearly marked as participation-only, completion-only, or unassessed.

### 10.4.3 Issuer identity.

Credential Objects shall identify the issuer, issuing institution, issuing program, issuing pathway, credential steward, and authorized issuing role. Issuer identity may include Nexus Academy, Risk Academy, an approved National Node, a university partner, a technical institute, a WILP host, a Foundry steward, a Registry steward, or another authorized body, depending on the credential class.

Issuer identity shall not imply that GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), a public authority, a professional body, an employer, a donor, an insurer, a capital reader, or a Project SPV has endorsed or validated the credential unless expressly recorded.

### 10.4.4 Assessment method.

Credential Objects shall record the assessment method, including quiz, exam, practical task, portfolio review, peer review, mentor review, host review, Studio exercise, simulation exercise, capstone review, public-safe output review, Foundry build review, WILP review, or competency panel review. Assessment methods shall specify review criteria, evidence requirements, pass criteria where applicable, review level, appeal route, and correction route.

Assessment shall not be automated for high-stakes credentialing by default. Where AI assists assessment, human review, bias review, transparency, appeal, and correction controls shall apply.

### 10.4.5 Expiry.

Credential Objects may include expiry dates where competence may become outdated because of changing technology, standards, law, public-safe guidance, data practices, AI governance, cyber risks, public authority requirements, safety requirements, or Nexus doctrine. Expiry shall be visible in Registry records and portfolio display where the credential is displayed.

Expired credentials shall not be displayed as current unless clearly labeled as expired or historical.

### 10.4.6 Renewal.

Credential renewal shall require evidence appropriate to the credential class, such as refresher learning, updated assessment, continued contribution, updated review, updated public-safe training, updated data or AI training, updated cyber training, updated safeguard training, updated WILP evidence, or updated Foundry evidence. Renewal shall be recorded with version, date, evidence basis, issuer, and review status.

Renewal shall not expand credential scope unless separately reviewed and recorded.

### 10.4.7 Suspension.

Credential suspension may occur where there is suspected misuse, evidence error, assessment integrity issue, public-safe issue, data incident, AI incident, identity issue, issuer issue, conflict issue, safeguard issue, legal hold, or correction need. Suspension shall update Registry status, portfolio display, Marketplace display where applicable, and downstream records.

Suspension shall be proportionate and correctionable. It shall include review pathway, notice where appropriate, appeal route where applicable, and reinstatement conditions.

### 10.4.8 Withdrawal.

Credential withdrawal may occur where the credential was issued in error, evidence is invalid, assessment integrity failed, issuer authority was absent, misuse occurred, public-safe conditions were breached, protected knowledge was exposed, identity was misrepresented, or correction requires removal. Withdrawal shall be recorded, versioned, and propagated to Registry records, Marketplace displays, ILA records, portfolio displays, and dependent credentials where applicable.

Withdrawal shall not erase audit history unless legally required. Withdrawn credentials shall not be represented as valid.

### 10.4.9 Registry status.

Credential Objects shall maintain Registry status, including draft, active, under review, suspended, expired, renewed, withdrawn, superseded, archived, or non-continuing. Registry status shall preserve status truth and correction history.

Registry status shall not convert a credential into a professional license, public authority credential, employment qualification, procurement qualification, finance signal, insurance signal, deployment approval, or execution authority.

### 10.4.10 Portfolio display.

Credential Objects may be displayed in learner portfolios, ILA-linked profiles, Marketplace profiles, Registry profiles, employer-readable summaries, public-good contributor profiles, or controlled portfolios according to learner permissions, privacy controls, youth safeguards, issuer rules, and display status. Display shall include credential name, issuer, scope, evidence basis summary, issue date, expiry where applicable, status, and boundary notices.

Portfolio display shall not imply endorsement, employment eligibility, hiring decision, public authority approval, procurement qualification, professional licensing, or deployment authorization.

## 10.5 Knowledge Product Governance

### 10.5.1 Plain-language summary.

A **Plain-Language Summary Object** shall translate complex evidence, methods, technology, risk, governance, data, AI, cyber, public authority, finance-readiness, safeguard, or handoff topics into clear, accessible language suitable for general audiences. It shall preserve accuracy, scope, uncertainty, public-safe limits, and correction pathways.

Plain-language simplification shall not remove material caveats, uncertainty, boundary notices, or sensitivity restrictions.

### 10.5.2 Expert summary.

An **Expert Summary Object** shall provide concise technical, institutional, legal-boundary, methodological, or domain-specific synthesis for expert audiences. It may support reviewers, maintainers, public authority learning participants, technical contributors, capital readers, insurers, donors, National Nodes, Competence Cells, Foundry teams, Studio users, or handoff recipients.

Expert summaries shall distinguish evidence, interpretation, assumptions, limitations, dependencies, unresolved questions, and boundary conditions.

### 10.5.3 Public-safe briefing.

A **Public-Safe Briefing Object** shall present approved information for external or semi-external audiences in a manner that avoids warning overclaim, approval overclaim, certification overclaim, finance overclaim, procurement overclaim, consent overclaim, provider validation overclaim, sponsor control overclaim, and execution overclaim. It may support Campaigns, Reports, Marketplace listings, Nexus Universe sessions, public authority learning rooms, community-facing communication, or National Portfolio communication.

Public-safe briefings shall include release class, audience, public-safe status, source notes, sensitivity exclusions, and correction route.

### 10.5.4 Technical guide.

A **Technical Guide Object** shall explain methods, software, data workflows, APIs, SDKs, connectors, dashboards, model cards, system cards, benchmark cards, digital twins, Studio workflows, DRI workflows, GRIx mappings, Grid inputs, TRL notes, repository governance, or handoff dependency preparation. It shall support reproducibility, implementation literacy, review, maintenance, and safe reuse.

Technical guides shall not provide deployment authorization, security certification, production approval, provider validation, procurement recommendation, or warranty by implication.

### 10.5.5 Community guide.

A **Community Guide Object** shall explain relevant Nexus, DDPGF, risk, resilience, data, technology, public-safe reporting, Campaign, Academy, Studio, or National Portfolio concepts for communities, civil society, public-interest participants, youth groups, place-based actors, and Indigenous participants where applicable. It shall be non-extractive, accessible, culturally sensitive, safeguard-aware, and respectful of protected knowledge.

Community guides shall not imply community consent, Indigenous consent, endorsement, permission to use protected knowledge, or authorization to implement in a community context.

### 10.5.6 Public authority learning guide.

A **Public Authority Learning Guide Object** shall support non-decisional learning by public authorities, regulators, public agencies, emergency management actors, public finance readers, ministries, local governments, or other public bodies. It may explain technologies, risks, evidence records, DRI outputs, Observatory outputs, Studio workflows, National Portfolio objects, public-safe Reports, finance-readiness questions, procurement boundaries, or handoff dependencies.

Public authority learning guides shall not constitute public authority advice, official policy, regulatory guidance, compliance determination, permit, license, approval, public warning, emergency command, public finance allocation, procurement decision, or governmental endorsement.

### 10.5.7 Contributor guide.

A **Contributor Guide Object** shall explain how contributors may participate in DDPGF objects, including software, data, models, reports, learning objects, dashboards, ontologies, schemas, APIs, Studio workflows, Foundry builds, Campaign objects, Registry records, Marketplace objects, or correction workflows. It shall address contribution rules, code of conduct, licensing, attribution, review, public-safe restrictions, data restrictions, AI-use restrictions, labor boundaries, iCRS recognition, and correction routes.

Contributor guides shall make clear that contribution does not create employment, ownership, authority, procurement status, provider validation, deployment authorization, or execution authority by implication.

### 10.5.8 Developer guide.

A **Developer Guide Object** shall explain software, API, data, model, dashboard, Studio, Registry, Marketplace, or integration development within DDPGF. It may include installation instructions, architecture notes, code examples, API examples, test instructions, security notes, SBOM guidance, dependency rules, contribution instructions, release process, and support class.

Developer guides shall distinguish sandbox use, learning use, public-good use, controlled use, and production use outside DDPGF default posture. A developer guide shall not create warranty, security certification, production approval, procurement recommendation, or deployment authorization.

### 10.5.9 Maintainer guide.

A **Maintainer Guide Object** shall define maintainer roles, review obligations, repository stewardship, release discipline, issue triage, vulnerability handling, dependency review, accessibility review, documentation review, public-safe review, correction handling, deprecation, withdrawal, archive, and handoff support. It may apply to software, data, models, learning objects, dashboards, ontologies, schemas, APIs, Reports, Marketplace objects, Registry records, Studio workflows, or Grid inputs.

Maintainer guides shall not make maintainer standing equivalent to professional licensing, public authority approval, provider validation, procurement qualification, or deployment authority.

### 10.5.10 Handoff literacy guide.

A **Handoff Literacy Guide Object** shall explain how public-good digital objects, evidence records, data context, method context, Studio context, Grid inputs, TRL notes, public-safe status, safeguard status, legal dependencies, public authority dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, and correction pathways may be transferred as lawful handoff context.

Handoff literacy guides shall emphasize that handoff transfers dependencies and context, not authority. They shall not authorize execution, procurement, finance, insurance, deployment, public authority action, provider selection, community consent, Indigenous consent, or operational command.

## 10.6 Learning and Credential Boundary Rules

### 10.6.1 Learning object is not professional certification.

A Learning Object may teach, train, orient, explain, test, simulate, assess, or support competence evidence, but it shall not constitute professional certification, licensure, regulated qualification, public authority credential, professional body recognition, or legal authority unless separately issued or recognized by a competent body through a recorded process.

### 10.6.2 Micro-credential is not license by default.

A Micro-Credential Object may evidence bounded learning, practice, contribution, assessment, or capability within a defined scope, but it shall not be treated as a professional license, public authority license, regulated credential, practice authorization, deployment authorization, or legal qualification by default.

### 10.6.3 Badge is not employment eligibility.

A Badge Object may display completion, contribution, participation, pathway progress, or recognition, but it shall not create employment eligibility, hiring decision, wage entitlement, immigration status, worker classification, procurement qualification, professional standing, or employer endorsement by implication.

### 10.6.4 OER use is not endorsement.

Use, reuse, translation, adaptation, citation, teaching, or distribution of an OER Object shall not imply endorsement by GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), any Nexus institution, public authority, sponsor, provider, university, employer, community, Indigenous institution, funder, insurer, capital reader, National Consortium Company, or Project SPV unless expressly and separately recorded.

### 10.6.5 MOOC completion is not procurement qualification.

Completion of a MOOC Object may create a learning record, completion record, ILA entry, competency evidence, or micro-credential eligibility where recorded, but it shall not create procurement qualification, vendor eligibility, supplier approval, tender advantage, public authority approval, professional license, employment guarantee, deployment authorization, financeability, insurability, or execution authority.

### 10.6.6 Public authority learning object is not public authority decision.

A Public Authority Learning Object may support understanding, policy literacy, technical literacy, regulatory learning, resilience learning, public finance literacy, procurement literacy, or emergency management literacy, but it shall not constitute public authority action, regulation, guidance, approval, permit, license, compliance finding, public warning, emergency command, public finance allocation, procurement decision, or governmental endorsement unless separately adopted through a competent public authority process outside DDPGF.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/x.-learning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.