# VIII. INTERFACES ## 8.1 API and Protocol Doctrine ### 8.1.1 API object defined. An **API Object** under DDPGF means any governed digital-public-good interface that permits software systems, data systems, model systems, Registry systems, Marketplace systems, Studio workflows, Campaign systems, Reports systems, DRI systems, Observatory systems, Academy systems, Foundry systems, Grid systems, TRL evidence systems, Proof Receipt systems, credential systems, National Portfolio systems, Nexus Universe systems, or lawful handoff systems to exchange, request, expose, transform, validate, retrieve, submit, update, or route information within a recorded scope. An API Object may include REST APIs, GraphQL APIs, streaming APIs, webhook interfaces, batch exchange interfaces, geospatial APIs, model-serving APIs, data access APIs, metadata APIs, Registry APIs, Marketplace APIs, Studio APIs, DRI APIs, Observatory APIs, credential APIs, Proof Receipt APIs, handoff APIs, and controlled internal interfaces. An API Object shall be treated as a governed interface, not merely a technical endpoint. It shall include recorded identity, purpose, steward, version, access class, authentication method, authorization model, data-use labels, AI-use labels where applicable, sensitivity class, logging requirements, rate limits, abuse controls, public-safe output rules, deprecation rules, correction pathway, and archive rule. API availability shall not create a data right, unrestricted access right, reuse right, AI-training right, public authority record, procurement status, provider validation, financeability, insurability, deployment authorization, or execution authority by implication. ### 8.1.2 Protocol object defined. A **Protocol Object** means any governed rule set, exchange pattern, object format, message format, interface profile, evidence-exchange structure, workflow structure, proof structure, credential structure, Registry interaction structure, Marketplace listing structure, Studio workflow structure, Grid or TRL evidence structure, handoff package structure, correction procedure, archive procedure, or interoperability rule used to make digital-public-good objects reusable, reviewable, transferable, discoverable, status-true, public-safe, and correctionable. A Protocol Object may exist as a specification, schema bundle, API contract, data-exchange profile, evidence-exchange profile, test profile, conformance-question record, implementation guide, reference implementation, protocol note, or controlled workflow rule. A Protocol Object shall support common operation across distributed Nexus actors without becoming a legal standard, certification regime, regulatory instrument, procurement framework, finance framework, public authority rule, community consent mechanism, or deployment authorization mechanism by default. Protocol Objects shall define how objects move, not who has authority to execute. Where a Protocol Object touches external standards, public authority functions, regulated sectors, telecommunications, data protection, AI governance, cybersecurity, public finance, insurance, or procurement, it shall include scope limits and no-overclaim notices. ### 8.1.3 Connector object defined. A **Connector Object** means a governed interface component that allows one system, platform, repository, data environment, model environment, workflow environment, Registry, Marketplace, Studio, dashboard, National Node, Observatory node, Campaign platform, Academy platform, or lawful handoff recipient system to connect to another system in a bounded and recorded manner. Connector Objects may include data connectors, repository connectors, cloud connectors, edge connectors, sensor connectors, model connectors, dashboard connectors, Registry connectors, Marketplace connectors, Studio connectors, DRI connectors, Observatory connectors, credential connectors, proof-receipt connectors, geospatial connectors, public authority learning connectors, and handoff-context connectors. A Connector Object shall include source system, destination system, access class, permission model, data minimization rules, transformation rules, logging rules, security controls, public-safe filtering rules, failure modes, deprecation rules, and correction rules. Connector availability shall not validate the source provider, destination provider, data provider, software provider, cloud provider, model provider, infrastructure provider, or implementation actor. A connector enables bounded interoperability; it does not endorse, certify, procure, finance, insure, approve, or authorize any connected actor or object. ### 8.1.4 Adapter object defined. An **Adapter Object** means a governed transformation component that converts, maps, translates, validates, normalizes, filters, masks, redacts, localizes, serializes, deserializes, or otherwise prepares data, metadata, schemas, model outputs, API responses, Registry fields, Marketplace listings, Studio workflow inputs, DRI indicators, Observatory signals, credential records, Proof Receipts, Report packages, Grid inputs, TRL notes, or handoff packages for use across different systems or contexts. Adapter Objects may support legacy-to-modern conversion, schema-to-schema translation, jurisdictional localization, language localization, public-safe transformation, secure-room output filtering, model-output formatting, and protocol-profile conversion. An Adapter Object shall not silently change meaning. It shall preserve provenance, transformation logic, source fields, target fields, lossy transformations, uncertainty, confidence, limitations, sensitivity labels, public-safe changes, and correction pathways. Adapter output shall not create semantic equivalence, legal equivalence, certification, official translation, public authority approval, procurement approval, financeability, insurability, or deployment authorization by implication. ### 8.1.5 Interoperability profile defined. An **Interoperability Profile** means a recorded combination of schemas, APIs, protocols, connectors, adapters, authentication rules, authorization rules, data-use labels, AI-use labels, message formats, vocabulary mappings, testing profiles, versioning rules, security controls, public-safe output rules, localization notes, deprecation rules, and boundary notices that enables specific digital-public-good objects or systems to work together within a defined scope. Interoperability Profiles may apply to DICE, GRIx, DRI, Nexus Observatory, Nexus Studio, Nexus Registry, Nexus Marketplace, Nexus Reports, Nexus Grid, TRL evidence notes, Nexus Academy, Risk Academy, Nexus Foundry, Nexus Campaigns, Nexus Universe, National Portfolios, National Nodes, and lawful handoff packages. An Interoperability Profile shall define what is interoperable, under what conditions, with what restrictions, at what version, for what use, and with what correction pathway. It shall not imply certification, compliance, standards conformance, data rights, procurement readiness, public authority approval, financeability, insurability, operational readiness, or execution authority. Interoperability shall be a public-good capability for controlled reuse and coordination, not an authorization to deploy. ### 8.1.6 Standards-interface without standards authority. DDPGF may maintain standards-interface records, standards mappings, standards gap records, conformance-question records, testing profile records, and standards-body interface records to improve interoperability, public-good quality, and readiness of Nexus objects. Such work shall be standards-aware and standards-literate, but shall not make DDPGF, Nexus, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Foundry, Nexus Grid, Nexus Registry, Nexus Marketplace, Nexus Studio, or any National Node a standards authority unless separately and lawfully constituted for that function. Standards-interface work shall identify relevant external standards, protocols, reference models, regulatory frameworks, public authority requirements, sectoral practices, open-source practices, digital public infrastructure patterns, AI governance frameworks, cybersecurity practices, data governance practices, telecommunications interfaces, cloud and compute patterns, geospatial conventions, disaster-risk frameworks, weather and climate data practices, and repository conventions. It shall convert such references into bounded interface records, not claims of certification, compliance, conformance, approval, or official status. ### 8.1.7 Open interface without unrestricted access. DDPGF shall support open interfaces where safe, lawful, useful, and public-good aligned. An open interface may expose documentation, schemas, metadata, public-safe APIs, sample data, public-safe outputs, open-source code, test harnesses, or reference implementations. Open interface status shall not mean unrestricted access to raw data, controlled data, personal data, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, secure-room material, handoff-recipient-only material, or restricted model outputs. Open interfaces shall include access controls where necessary, rate limits, abuse prevention, API keys where appropriate, public-safe filtering, data minimization, license notices, support notices, no-warranty notices, no-certification notices, no-procurement notices, no-finance notices, no-public-authority notices, no-consent notices, no-deployment notices, no-execution notices, and correction pathways. ### 8.1.8 Interoperability as public-good capability. Interoperability shall be treated as a public-good capability that allows distributed Nexus objects, institutions, contributors, National Nodes, National Working Groups, Competence Cells, public authorities in learning posture, universities, providers, sponsors, hosts, capital readers, insurers, donors, communities, and lawful handoff recipients to coordinate without platform capture, semantic drift, uncontrolled data extraction, hidden authority, provider lock-in, or execution by implication. Interoperability shall enable reuse, transparency, portability, localization, public-safe reporting, evidence traceability, standards awareness, repository continuity, digital sovereignty, correction propagation, and lawful handoff dependency clarity. Interoperability shall be disciplined by record. No system shall be considered interoperable merely because it connects technically. Interoperability shall require scope, version, permissions, data labels, AI-use labels, security controls, public-safe controls, review status, support status, steward identity, and correction pathway. ## 8.2 API Object Classes ### 8.2.1 Public APIs. **Public APIs** are API Objects intended for public-safe access to approved data, metadata, reports, Registry summaries, Marketplace listings, public-safe indicators, public-safe dashboards, public documentation, learning objects, campaign objects, or other open digital-public-good objects. Public APIs shall expose only content classified as open public or controlled public, as applicable, and shall apply rate limits, abuse controls, logging, public-safe output filtering, license notices, support notices, and boundary notices. A Public API shall not expose raw restricted data, protected knowledge, confidential material, public authority-sensitive data, handoff-recipient-only material, secure-room material, or information that may create public warning, official decision, procurement, finance, insurance, consent, deployment, or execution implications. ### 8.2.2 Controlled APIs. **Controlled APIs** are API Objects available only to approved users, systems, rooms, institutions, National Nodes, public authority learning participants, reviewers, maintainers, handoff recipients, or other authorized actors within a defined permission model. Controlled APIs may expose restricted metadata, controlled datasets, model outputs, Studio workflow inputs, DRI records, Observatory records, Grid evidence, TRL notes, Registry records, Marketplace review data, secure-room outputs, or handoff package components. Controlled APIs shall require authentication, authorization, access logging, use restriction, data minimization, purpose limitation, output review where necessary, and correction pathways. Controlled API access shall not create data rights, reuse rights, public authority approval, finance approval, procurement status, insurance status, deployment authorization, or execution authority. ### 8.2.3 Internal APIs. **Internal APIs** are API Objects used within Nexus-controlled systems, internal workflows, platform services, data processing pipelines, Registry operations, Marketplace operations, Studio operations, Reports operations, Foundry operations, DICE operations, GRIx operations, DRI operations, Observatory operations, Academy operations, Campaign operations, Grid operations, or National Node operations. Internal APIs may support automation, data synchronization, internal review, workflow state changes, access management, logging, correction, archive, and dependency propagation. Internal APIs shall remain governed even where not externally exposed. Internal status shall not remove security, privacy, public-safe, data sovereignty, protected knowledge, AI-use, logging, access, review, or correction obligations. Internal APIs shall not be used to bypass governance controls, create hidden authority, silently alter records, or circumvent public-good stack / enterprise-stack separation. ### 8.2.4 Data APIs. **Data APIs** are API Objects that provide structured access to data, metadata, data dictionaries, codebooks, schemas, data availability statements, lineage records, quality records, DRI datasets, Observatory datasets, National Portfolio datasets, or controlled data outputs. Data APIs shall carry data-use labels, AI-use labels, rights statements, source class, sensitivity class, public-safe status, lineage information, retention rules, and correction pathways. A Data API shall not create unrestricted data rights, consent, AI-training permission, cross-border transfer permission, public authority record status, reuse permission, publication permission, or handoff permission by implication. Sensitive Data APIs shall prefer metadata-first access, compute-to-data, secure-room access, or controlled output review where appropriate. ### 8.2.5 Model APIs. **Model APIs** are API Objects that provide access to statistical models, machine-learning models, foundation-model interfaces, retrieval-augmented systems, classifiers, forecasting models, simulation models, digital twin models, risk models, optimization models, decision-support models, evaluation harnesses, or agentic workflows. Model APIs shall include model identity, model card link, system card link where applicable, benchmark record link where applicable, intended-use notice, prohibited-use notice, data provenance status, AI-use label, human-review rule, logging, output classification, rate limits, abuse prevention, and incident response pathway. Model API access shall not constitute AI safety certification, public authority decision authority, automated determination authority, financeability, insurability, procurement readiness, deployment authorization, or execution authority. High-risk, public authority-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, protected knowledge, or finance-sensitive Model APIs shall require controlled access and human review. ### 8.2.6 Registry APIs. **Registry APIs** are API Objects that allow creation, retrieval, update, validation, synchronization, or public-safe display of Registry records, status records, version records, review records, correction records, withdrawal records, recall records, archive records, support records, provider contribution records, sponsor support records, public authority participation records, and object relationship records. Registry APIs shall protect status truth and correction history. Registry APIs shall not permit silent status changes, unauthorized overwrite, hidden deletion, undisclosed correction, or unrecorded authority claims. Registry API output shall not create certification, approval, legal status, procurement status, financeability, insurability, public authority status, consent, deployment authorization, or execution authority. ### 8.2.7 Marketplace APIs. **Marketplace APIs** are API Objects that support listing, discovery, search, filtering, update, review, delisting, support discovery, demand-signal capture, translation, accessibility metadata, and handoff-awareness display for Marketplace objects. Marketplace APIs shall include listing status, Registry link, support class, license class, access class, review status, public-safe status, provider-neutrality notes, sponsor-boundary notes, procurement-neutrality notes, finance-boundary notes, correction pathway, and delisting pathway. Marketplace API access, display, download, ranking, search result, featured placement, reuse signal, or support request shall not create endorsement, procurement recommendation, provider validation, finance signal, insurance signal, deployment authorization, or execution authority. ### 8.2.8 Studio APIs. **Studio APIs** are API Objects that support controlled runtime workflows, dashboards, simulations, digital twins, AI workflow review, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader room workflows, insurance-reader room workflows, Nexus Universe workflows, and handoff demonstration workflows. Studio APIs shall enforce role-based permissions, no-command rules, no-write-back rules, output review, logging, data export restrictions, public-safe restrictions, shutdown triggers, correction triggers, and archive rules. Studio API access shall not create decision authority, operational command, deployment authorization, public authority action, finance approval, insurance underwriting, procurement readiness, consent, or execution authority. ### 8.2.9 Campaign APIs. **Campaign APIs** are API Objects that support campaign records, signatures, pledges, support records, volunteer records, team and chapter tools, ambassador tools, quest and bounty tools, campaign dashboards, public-safe storytelling, public Reports, Support Ledgers, DICE contributions, DRI contributions, Working Group formation records, Competence Cell formation records, Nexus Universe routing, correction channels, and archive records. Campaign APIs shall include trust and safety controls, fraud controls, consent controls, public-safe controls, youth safeguards where applicable, data minimization, and correction channels. Campaign API activity shall not convert signatures into votes, pledges into binding finance, support into control, volunteer participation into employment, public attention into public authority approval, community participation into consent, donor interest into commitment, or campaign success into execution authority. ### 8.2.10 Reports APIs. **Reports APIs** are API Objects that support report metadata, publication packages, repository links, DOI metadata where applicable, citation files, data availability statements, AI-use statements, public-safe abstracts, controlled knowledge exclusions, correction notices, withdrawal notices, archive records, related identifiers, and distribution. Reports APIs shall distinguish public-safe public content from controlled, restricted, secure-room-only, or archive-only material. Reports API access shall not make a publication an approval, public warning, official decision, country ranking, certification, finance signal, procurement signal, unrestricted data right, deployment authorization, or execution authority. ### 8.2.11 DRI APIs. **DRI APIs** are API Objects that support indicator records, signal records, confidence labels, uncertainty labels, dashboard records, hotspot records, multi-hazard records, cascade records, national DRI contributions, public-safe intelligence summaries, correction records, and archive records. DRI APIs shall preserve no-warning, no-rating, no-public-authority, no-finance, no-insurance, and no-investment-signal boundaries. DRI API outputs shall not be used as public warnings, official forecasts, insurance scores, investment signals, procurement signals, emergency command, or public authority decisions. DRI APIs serving sensitive locations, infrastructure, health, cyber, community, or protected knowledge contexts shall require public-safe filtering and access controls. ### 8.2.12 Observatory APIs. **Observatory APIs** are API Objects that support Observatory nodes, hubs, regional clusters, national dense Nexus cores, edge signals, sensor networks, geospatial signals, Earth observation signals, digital twin needs, degraded-mode awareness, public-safe Observatory outputs, and correction records. Observatory APIs shall include source records, sensitivity labels, location controls, confidence labels, uncertainty labels, access controls, public-safe view rules, and archive rules. Observatory API output shall not create surveillance authority, official maps, public warnings, emergency command, public authority decisions, infrastructure disclosure permission, protected knowledge permission, finance signals, insurance signals, procurement signals, or execution authority. ## 8.3 Protocol Object Classes ### 8.3.1 Data-exchange protocols. **Data-Exchange Protocols** shall define how data, metadata, lineage, quality indicators, sensitivity labels, rights statements, data-use labels, AI-use labels, access classes, public-safe transformations, and correction records are exchanged across DICE, National Nodes, repositories, Registry, Marketplace, Studio, Reports, DRI, Observatory, Grid, TRL, and handoff systems. These protocols shall preserve data minimization, purpose limitation, provenance, access control, public-safe filtering, and correction. Data-exchange protocols shall not grant data rights, unrestricted reuse rights, AI-training rights, cross-border transfer permission, public authority status, handoff permission, or publication permission by implication. ### 8.3.2 Evidence-exchange protocols. **Evidence-Exchange Protocols** shall define how evidence packs, method notes, evaluation records, benchmark records, model cards, system cards, data provenance records, software quality records, Studio outputs, Grid inputs, TRL notes, DRI records, Observatory records, Reports, and handoff evidence contexts are structured, referenced, transmitted, reviewed, versioned, corrected, and archived. These protocols shall require source, scope, method, assumptions, limitations, confidence, uncertainty, review status, public-safe status, safeguard status, and correction pathway. Evidence-exchange shall not certify evidence, approve systems, create financeability, create insurability, create procurement readiness, create public authority approval, authorize deployment, or execute projects. ### 8.3.3 Registry protocols. **Registry Protocols** shall define how digital-public-good objects are registered, updated, versioned, status-labeled, corrected, suspended, withdrawn, recalled, superseded, archived, or marked non-continuing. Registry Protocols shall protect status truth, version integrity, support status, review history, correction history, object relationships, and boundary notices. Registry Protocols shall not transform Registry status into certification, approval, legal status, procurement status, financeability, insurability, deployment authorization, or execution authority. ### 8.3.4 Marketplace listing protocols. **Marketplace Listing Protocols** shall define how objects become discoverable, listed, updated, translated, localized, filtered, categorized, support-labeled, delisted, corrected, or archived in the Nexus Marketplace. Listing Protocols shall require Registry linkage, object identity, version, steward, license, access class, support class, public-safe status, review status, provider-neutrality notes, sponsor-boundary notes, procurement-neutrality notes, finance-boundary notes, and correction pathway. Marketplace Listing Protocols shall not create endorsement, procurement recommendation, provider validation, sponsor influence, finance signal, insurance signal, deployment approval, or handoff authorization. ### 8.3.5 Studio workflow protocols. **Studio Workflow Protocols** shall define how controlled runtime workflows are created, accessed, run, observed, reviewed, exported, shut down, corrected, and archived. They shall apply to dashboards, digital twins, simulations, AI workflows, data workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader room workflows, insurance-reader room workflows, Nexus Universe workflows, and handoff demonstration workflows. Studio Workflow Protocols shall include no-command rules, no-write-back rules, output review, access logging, data export restrictions, AI-use restrictions, public-safe restrictions, shutdown triggers, correction triggers, and archive rules. They shall not authorize operational command, deployment, official decision, finance approval, underwriting, procurement, consent, or execution. ### 8.3.6 Proof receipt protocols. **Proof Receipt Protocols** shall define how Proof Receipts are created, linked, validated, displayed, corrected, and archived. Proof Receipts may record contributions, reviews, releases, corrections, Docket movements, Registry updates, Marketplace listings, Studio workflow events, Grid inputs, TRL notes, Reports, Nexus Universe outputs, learning completions, credential events, support actions, and handoff package events. Proof Receipt Protocols shall prove recordable occurrence within scope, not quality, approval, certification, consent, financeability, insurability, procurement readiness, deployment authorization, or execution. ### 8.3.7 Credential protocols. **Credential Protocols** shall define how learning records, micro-credentials, digital badges, ILA entries, WILP records, skills wallet records, competency evidence records, reviewer records, mentor records, contribution records, expiries, renewals, suspensions, withdrawals, appeals, corrections, and public display settings are structured and exchanged. Credential Protocols shall preserve learner privacy, evidence basis, issuer identity, review status, expiry, correction history, revocation status, and boundary notices. Credential Protocols shall not create degrees, professional licenses, employment guarantees, immigration status, wage status, procurement eligibility, public authority approval, deployment authorization, community consent, or execution authority. ### 8.3.8 Handoff package protocols. **Handoff Package Protocols** shall define how evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive rules are packaged for lawful downstream recipients. These protocols shall support controlled public-good-to-enterprise interface without collapsing public-good and enterprise stacks. Handoff Package Protocols shall transfer context and dependencies, not authority. They shall not authorize execution, procurement, finance, insurance, public authority action, deployment, provider selection, consent, or reliance beyond the recorded scope. ### 8.3.9 Correction protocols. **Correction Protocols** shall define how errors, overclaims, defects, incidents, vulnerabilities, data issues, AI incidents, public-safe issues, protected knowledge issues, public authority boundary issues, finance boundary issues, procurement boundary issues, provider validation issues, sponsor control issues, consent overclaims, handoff overclaims, and execution overclaims are identified, recorded, triaged, contained, corrected, communicated, propagated, and archived. Correction Protocols may trigger claims freeze, data freeze, technical freeze, model freeze, API freeze, Marketplace delisting, Registry status update, public-safe notice, handoff recall, and archive or reinstatement. Correction Protocols shall preserve trust by making error visible and repairable. Correction shall not be treated as failure of the public-good system; it is part of the system’s operating doctrine. ### 8.3.10 Archive protocols. **Archive Protocols** shall define how objects, APIs, protocols, connectors, adapters, schemas, reports, datasets, models, dashboards, Studio workflows, Registry records, Marketplace listings, Grid records, TRL notes, Proof Receipts, credentials, campaign objects, National Portfolio objects, Nexus Universe outputs, and handoff packages are preserved, marked historical, restricted, sealed, superseded, withdrawn, recalled, deprecated, or made non-continuing. Archive Protocols shall include metadata, access class, license status, support status, public-safe status, correction history, successor links, retention rules, and archive-not-current notices. Archive status shall not create current authority. Archived objects shall not be used as current evidence, current API authority, current protocol authority, current Registry truth, current Marketplace listing, current Studio workflow, current Grid status, current TRL status, or current handoff context unless separately reviewed and reinstated. ## 8.4 Interoperability Controls ### 8.4.1 Versioning. All API Objects, Protocol Objects, Connector Objects, Adapter Objects, Interoperability Profiles, schemas, mappings, reference implementations, documentation, test profiles, and interface records shall be versioned. Version records shall identify object identity, version number, release date, steward, changes, compatibility status, breaking changes, migration requirements, deprecation status, correction history, security notes, public-safe notes, and archive rule. Versioning shall prevent silent drift. Where version changes affect data interpretation, AI-use permissions, public-safe outputs, Registry status, Marketplace discovery, Studio workflows, Grid inputs, TRL notes, Reports, National Portfolios, Nexus Universe outputs, or handoff packages, downstream dependencies shall be reviewed and corrected where necessary. ### 8.4.2 Backward compatibility. Backward compatibility shall be considered where interfaces support active users, National Nodes, repositories, public-safe reporting, DRI dashboards, Observatory workflows, Marketplace listings, Registry records, Studio workflows, Academy objects, Campaign objects, Grid inputs, TRL notes, or handoff contexts. Where backward compatibility is not possible, migration notices, version windows, adapter guidance, deprecation notices, successor links, support class notes, and correction pathways shall be provided. Backward compatibility shall not override security, privacy, public-safe, protected knowledge, data sovereignty, AI safety, cyber, safeguard, or legal boundary controls. An unsafe or overclaiming interface may be suspended, withdrawn, recalled, or archived even where backward compatibility would otherwise be preferred. ### 8.4.3 API authentication. API authentication shall establish the identity of users, systems, services, rooms, repositories, platforms, National Nodes, public authority learning participants, reviewers, maintainers, contributors, or lawful handoff recipients accessing an API Object. Authentication may include API keys, service accounts, federated identity, signed requests, token-based access, multi-factor authentication where appropriate, room-specific credentials, and short-lived credentials for controlled contexts. Authentication shall not itself authorize access. Identity proof shall be combined with authorization, purpose limitation, access class, data-use label, AI-use label, sensitivity label, logging, and review rules. ### 8.4.4 Authorization. Authorization shall determine what an authenticated user or system may access, submit, modify, retrieve, export, list, run, review, correct, archive, or hand off. Authorization shall be role-based, attribute-based, purpose-based, context-based, room-based, jurisdiction-sensitive, and object-sensitive where appropriate. Authorization shall distinguish read, write, update, delete, correct, approve within scope, list, export, execute workflow, trigger workflow, and archive permissions. Authorization shall enforce public-good stack / enterprise-stack separation and shall prevent hidden public authority action, finance activity, procurement activity, insurance activity, community consent inference, Indigenous consent inference, operational command, deployment authorization, or execution by API action. ### 8.4.5 Rate limits. Rate limits shall be applied to prevent abuse, extraction, denial-of-service conditions, scraping, unauthorized aggregation, model harvesting, credential harvesting, graph extraction, sensitive-location inference, campaign manipulation, Registry manipulation, Marketplace manipulation, or DRI and Observatory misuse. Rate limits may vary by user class, system class, object class, sensitivity class, support class, room type, and public-safe status. Rate limits shall not be represented as service-level guarantees unless separately contracted. Rate limits are controls, not warranties. ### 8.4.6 Logging. API, protocol, connector, adapter, and interoperability actions shall be logged where appropriate to preserve accountability, security, auditability, correctionability, support, incident response, provenance, and institutional memory. Logs may include timestamp, authenticated identity, system identity, action type, object identity, source, destination, version, access class, result, error code, export status, public-safe status, and correction reference. Logging shall respect privacy, data minimization, protected knowledge, security, and sensitive-context controls. Logs shall not be used for unauthorized surveillance, worker monitoring, social scoring, public authority enforcement, finance scoring, insurance scoring, procurement scoring, or community profiling. ### 8.4.7 Abuse prevention. Abuse prevention shall detect and prevent misuse of APIs, protocols, connectors, adapters, and interoperability profiles, including scraping, credential stuffing, denial of service, prompt injection, model extraction, sensitive data inference, protected knowledge extraction, unauthorized export, mass profile collection, Marketplace manipulation, Registry manipulation, campaign manipulation, false proof receipts, fake credentials, dependency poisoning, malicious connectors, and public-safe output evasion. Abuse prevention measures may include throttling, blocking, authentication tightening, human review, output restriction, claims freeze, data freeze, technical freeze, Marketplace delisting, Registry status change, API suspension, connector suspension, credential revocation, proof receipt correction, and archive. ### 8.4.8 Data minimization. API Objects, Protocol Objects, Connector Objects, Adapter Objects, and Interoperability Profiles shall transmit, expose, collect, retain, and log only the data required for the recorded purpose. Data minimization shall apply to personal data, youth data, health-sensitive data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, finance-sensitive data, insurance-sensitive data, procurement-sensitive data, and handoff-recipient-only data. Data minimization shall prefer metadata-only records, public-safe summaries, aggregation, masking, synthetic data, redaction, compute-to-data, secure-room access, data-room access, and controlled output review where appropriate. ### 8.4.9 Public-safe output filtering. Public-safe output filtering shall ensure that API responses, protocol outputs, connector outputs, adapter outputs, dashboard outputs, Studio outputs, DRI outputs, Observatory outputs, Reports outputs, Registry summaries, Marketplace listings, credential displays, graph views, and handoff summaries do not expose restricted data, sensitive locations, protected knowledge, personal data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, or overclaiming language. Public-safe filtering shall include no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-deployment language, no-execution language, uncertainty labels, confidence labels, source notes, limitations, and correction notices where applicable. ### 8.4.10 Deprecation notices. Deprecation notices shall be issued when an API, protocol, connector, adapter, schema, endpoint, field, version, interoperability profile, test profile, reference implementation, or workflow is no longer preferred for active use. Deprecation notices shall identify the affected object, reason, successor object where applicable, effective date, migration guidance, support window, risk notes, correction pathway, and archive rule. Deprecated interfaces shall not be silently reused for new meanings. Where continued use creates risk, overclaim, security exposure, data exposure, public-safe risk, or handoff risk, the interface may be suspended, withdrawn, recalled, or archived. ## 8.5 Standards Interface ### 8.5.1 Standards mapping. Standards mapping shall identify relationships between DDPGF objects and external standards, specifications, protocols, frameworks, reference architectures, terminology systems, data models, API conventions, software practices, AI governance systems, cybersecurity practices, data governance systems, geospatial conventions, telecommunications interfaces, cloud and compute practices, disaster-risk frameworks, weather and climate data practices, digital public infrastructure patterns, open-source governance practices, and repository practices. Standards mapping may include exact relationship, partial relationship, gap relationship, conflict relationship, optional alignment, national localization requirement, or no relationship. Standards mapping shall be recorded with source, version, scope, mapping type, limitations, reviewer, date, confidence, and correction pathway. Standards mapping shall not imply standards adoption, certification, conformance, legal compliance, public authority approval, procurement readiness, financeability, insurability, or deployment authorization. ### 8.5.2 Standards gap records. Standards Gap Records shall identify where DDPGF objects, Nexus objects, protocols, APIs, data models, AI systems, dashboards, Studio workflows, Grid inputs, TRL notes, Reports, National Portfolio objects, or handoff packages lack sufficient mapping, guidance, evidence, review, interoperability, security, accessibility, localization, public-safe controls, safeguard controls, or external standards clarity. Such gaps may become Docket items, Foundry quests, bounties, builds, Reports, Academy learning objects, Studio workflows, Grid review items, TRL evidence notes, or handoff dependency notes. A Standards Gap Record shall not imply non-compliance unless separately determined by competent authority. It shall identify uncertainty, work needed, evidence needed, and review needed. ### 8.5.3 Conformance-question records. Conformance-Question Records shall record questions about whether an object, interface, protocol, schema, API, model, dataset, dashboard, workflow, report, credential, or handoff package may align with a particular external standard, internal protocol, interoperability profile, testing profile, or implementation requirement. A Conformance-Question Record shall include the standard or profile, version, object, scope, evidence available, evidence missing, test approach, reviewer, unresolved questions, limitations, and boundary notices. A Conformance-Question Record shall not be a conformance certificate, compliance determination, audit opinion, approval, procurement qualification, finance signal, insurance signal, public authority finding, or deployment authorization. It remains a question record until separately resolved by competent authority or appropriate governance. ### 8.5.4 Testing profile records. Testing Profile Records shall define how an API, protocol, connector, adapter, schema, software object, data object, model object, dashboard, Studio workflow, Registry record, Marketplace listing, credential object, Proof Receipt, Grid input, TRL note, or handoff package may be tested for interoperability, structure, data quality, security behavior, accessibility, public-safe output, error handling, backward compatibility, and correction behavior. Testing Profile Records may include test cases, sample payloads, validation rules, expected errors, version coverage, test environment, limitations, and result reporting. Testing Profile Records shall not create certification, conformance certification, security certification, safety approval, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution authority. ### 8.5.5 Standards-body interface records. Standards-Body Interface Records shall document interactions, submissions, observations, participation, mappings, comments, liaison notes, consultation records, learning records, or reference records involving external standards bodies, technical committees, public authorities, industry consortia, open-source foundations, digital public infrastructure communities, disaster-risk bodies, weather and climate data communities, telecommunications bodies, data governance bodies, AI governance communities, cybersecurity communities, geospatial communities, and other standards-relevant actors. Participation in or reference to a standards body shall not imply endorsement by that body, adoption by that body, certification by that body, public authority approval, standards authority for Nexus, or authority to represent a standards body unless separately and lawfully recorded. ### 8.5.6 Protocol authority boundary. Protocol authority, where created, shall remain separate from default DDPGF operation unless specifically constituted by an authorized Nexus instrument. DDPGF may prepare, maintain, document, and implement Protocol Objects for public-good interoperability, but it shall not claim legal standards authority, certification authority, regulatory authority, procurement authority, public authority status, finance authority, insurance authority, or deployment authority by implication. Where a Protocol Authority exists or is later established, DDPGF shall preserve role separation among GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), protocol authority actors, public authorities, standards bodies, National Nodes, National Consortium Companies, Project SPVs, providers, sponsors, and lawful implementation actors. ### 8.5.7 GCRI / GRF / GRA role separation. Standards-interface work shall preserve the distinct roles of the institutional triad. **GCRI** may steward evidence, methods, observability, ontology, public-good R\&D, public-good software, open technical baselines, verifiable compute, technical interfaces, and evidence-bearing protocol work. **The Global Risks Forum (GRF)** may steward public-good legitimacy, claims discipline, Registry status truth, recognition-interface language, maturity-record discipline, public-safe reporting, stakeholder formation, public narrative, and correction. **The Global Risks Alliance (GRA)** may steward finance-readiness, capital-readability, insurance-readiness, disaster-risk-finance literacy, diligence-gap records, no-reliance controls, and regulated-perimeter discipline. No standards-interface activity shall merge these roles, create hidden agency, create shared liability, collapse authority, imply certification, imply public authority status, imply finance activity, imply insurance activity, imply procurement activity, or imply execution authority. ### 8.5.8 No standards authority overclaim. DDPGF standards-interface language shall avoid implying that DDPGF, Nexus, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Foundry, Nexus Grid, Nexus Registry, Nexus Marketplace, Nexus Studio, Nexus Reports, Nexus Universe, National Nodes, National Working Groups, Competence Cells, providers, sponsors, or contributors create, adopt, certify, enforce, or adjudicate external standards unless separately and lawfully recorded. Standards-aware design shall improve quality and interoperability; it shall not create standards authority by implication. Where public-facing materials reference standards, specifications, protocols, bodies, frameworks, or technical practices, they shall include appropriate boundary language: mapping is not certification; testing is not conformance certification; interoperability is not approval; protocol reference is not legal standard; API access is not data right; connector availability is not provider validation; and benchmark result is not general validation. ## 8.6 API and Protocol Boundary Rules ### 8.6.1 API access is not data right. Access to an API shall not create ownership, license, reuse permission, publication permission, AI-training permission, cross-border transfer permission, download permission, handoff permission, or unrestricted data right. API access shall remain governed by recorded permissions, data-use labels, AI-use labels, sensitivity labels, licenses, access classes, room controls, public-safe rules, and correction pathways. ### 8.6.2 Interoperability is not certification. Interoperability means that objects, systems, schemas, protocols, connectors, adapters, or workflows can exchange or interpret information within a recorded scope. It shall not constitute certification, compliance, safety approval, security certification, quality approval, public authority approval, financeability, insurability, procurement readiness, deployment authorization, or execution authority. ### 8.6.3 Protocol object is not legal standard by default. A Protocol Object shall be a governed public-good operating object unless separately adopted as a legal standard, regulatory instrument, procurement requirement, contractual requirement, or official requirement by competent authority. Protocol documentation, reference implementation, testing profile, or Registry record shall not create legal standard status by implication. ### 8.6.4 Connector availability is not provider validation. The existence, availability, listing, use, or support of a Connector Object shall not validate, endorse, certify, approve, prefer, procure, finance, insure, or authorize the connected provider, platform, data source, model source, infrastructure provider, cloud provider, software provider, public authority participant, sponsor, host, operator, or handoff recipient. Connector availability means only that a technical interface exists within a recorded scope and control model. ### 8.6.5 Testing profile is not conformance certification. A Testing Profile may define how a thing can be tested and may record test results within scope. It shall not itself be a conformance certification, audit opinion, compliance determination, security certification, safety approval, standards certification, procurement qualification, finance signal, insurance signal, public authority approval, deployment authorization, or execution authority. ### 8.6.6 Standards reference is not standards authority. Reference to a standard, standards body, protocol, framework, specification, guideline, public authority document, industry practice, open-source practice, disaster-risk framework, weather and climate data practice, telecommunications interface, AI governance framework, cybersecurity practice, data governance practice, or repository practice shall not make DDPGF, Nexus, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus Foundry, Nexus Grid, Nexus Registry, Nexus Marketplace, Nexus Studio, National Nodes, or contributors a standards authority. Standards references shall support awareness, mapping, interoperability, and public-good quality only within recorded limits. --- # 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/viii.-interfaces.md?ask= ``` 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.