Frequently asked questions about the Seven Layer Models for Digital Public Infrastructure

The Seven Layer Model for Digital Public Infrastructure is a governance reference model that sequences how public authority becomes a lawful, reviewable, and enforceable digital outcome. It is used to allocate decision rights, accountability, assurance scope, and change control across the full lifecycle of Digital Public Infrastructure that supports public services with potential legal effect. The model is law-first and institution-first. It treats records, decision logic, execution, and interface design as constrained by legal authority, institutional mandate, and an evidence pathway that preserves contestability and effective remedy under real-world reliance. The meaning of each layer is defined by what it governs, who is accountable, and what must remain demonstrable under oversight. The Seven Layer Model for Digital Public Infrastructurel is unrelated to the OSI networking model. Similar layer counts do not imply conceptual overlap, architectural equivalence, or any shared semantics.

Public authority flows from law and valid delegation, not from configuration. Technology can implement authorised powers, but it cannot create them, expand them, or legitimise them after deployment.

These terms separate lawful public action from reusable artefacts. Digital Public Infrastructure is a nationally governed, cross-domain foundation of shared capabilities and trust mechanisms that enables multiple public services to operate at scale through common functions, interoperability arrangements, and assurance practices. A Digital Public Service is a public-facing service outcome delivered under lawful authority, defined by an authorised procedure, an accountable institution, and a specified outcome in a particular domain. A Digital Public Function is a legally bounded public function assigned to an accountable institution that performs a defined administrative or regulatory act within an authorised procedure and may contribute to, or directly produce, legal effect. A Digital Public Good is a reusable digital artefact such as software, specifications, open components, or reference implementations intended for ecosystem reuse, but it carries no lawful authority or institutional accountability by default. A practical classification test is to locate legality and accountability. If legality is produced only through domestic authority and procedure, the item is a function or a service. If it is a reusable artefact with no built-in mandate, it is a public good. If it is reused across domains under national governance, it is infrastructure.

A Digital Public Function is a legally bounded public function, assigned to an accountable institution, that performs a defined administrative or regulatory act within an authorised procedure and may contribute to, or directly produce, legal effect. Typical functions include identity proofing decisions, eligibility determinations, registration updates, certification issuance, and validation decisions. When implemented as software, the software does not become the authority. Authority remains with the competent institution, and the function remains valid only within the authorised procedure and its controls.

A Digital Public Service is a public-facing service outcome delivered to persons or legal entities under lawful authority, defined by an authorised procedure, an accountable institution, and a specified outcome in a particular domain such as health, taxation, licensing, or social protection. A service orchestrates one or more Digital Public Functions and consumes Digital Public Infrastructure capabilities to achieve the outcome. Delivery channels and interfaces may vary, yet service identity remains anchored in lawful outcome, procedure, and accountability rather than in the platform used to deliver it.

Digital Public Goods may be adopted to implement components of Digital Public Infrastructure or workflows within a Digital Public Service. Legal validity, accountability, assurance obligations, and effective remedies arise from domestic governance and authorised procedures rather than from the artefact being designated as a Digital Public Good. Digital Public Infrastructure is defined by reuse and governance scope, not by sector outcomes or a single application. Legal effect does not arise from infrastructure alone; legal effect occurs only where a competent authority mandates the execution of a Digital Public Function within an authorised procedure and assigns accountable institutional responsibility for the resulting evidence and remedies.

Enterprise architecture aligns technology domains, but it does not establish legal authority, institutional mandate, canonical record status, or enforceable remedy. The Seven Layer Model begins with legal authority and institutional mandate and treats technical choices as subordinate to attributable public power, evidence integrity, and reviewability.

Valid legal authority, an assigned accountable institution, an authorised procedure, evidence capability sufficient for review, and an operable route to oversight and remedy before any binding outcome is relied upon.

An enabling legal basis that defines permitted functions, allocates powers, constrains delegation and automation where required, and clarifies the conditions under which digital records and outcomes are recognised as evidence or carry legal effect.

Each function and service must have an institutional carrier with responsibility for procedure, evidence, disclosure, correction, and remedy. Vendors and platforms may execute tasks, but they do not hold decision rights or ultimate accountability.

A registry is canonical when it is legally recognised, assigned to an accountable custodian, and operated with provenance, retention, and disclosure controls sufficient for evidentiary integrity and lawful reliance.

Rules and decision logic may be implemented in software, but they produce legal effect only when authorised and executed under institutional mandate and procedure. Governance of decision logic is continuous and includes controlled change, auditability, testing, and rollback readiness.

A formally issued outcome produced under lawful authority through an authorised procedure, with attributable issuance and evidence sufficient for review, correction, and remedy.

By ensuring that access, disclosure, receipts, correction requests, and appeal initiation are usable across channels, with clear procedural state, timelines, and non-discriminatory access to assistance, so rights are operational rather than theoretical.

By guaranteeing independent scrutiny, operable appeal and complaint routes, supervision interfaces, and enforceable correction powers so outcomes can be reviewed, reversed, or rectified under recognised authority.

The system may function operationally but loses lawful enforceability, attributable accountability, evidence integrity, or remedy operability. Omission enables boundary substitution where platform control behaves like authority without delegation.

Yes, but only in a non-binding mode that does not create, change, or extinguish rights, status, or obligations. A pilot may test usability, technical performance, interoperability, and operational readiness, but it cannot substitute for legal authority, institutional mandate, or oversight and remedy when the outcome is intended to have public effect. DPI pilots may validate shared capability operation and dependency surfaces, but must not become de facto authority through reliance for binding outcomes. DPS pilots may test end-to-end service journeys, yet must remain demonstrative unless accountable issuance and contestability are operable. DPF pilots may simulate decisions and evidence generation, but any real determination must be grounded in delegated authority and authorised procedure. DPG pilots may be deployed for evaluation, but lawful operation arises only after domestication into domestic governance, assurance obligations, and oversight and remedy.

No. Interoperability must remain subordinate to domestic authority, institutional assignments, and procedural safeguards. Technical protocols cannot substitute for jurisdictional control or weaken contestability.

As a sequencing safeguard. Funding should prioritise programmes that begin with legal authority and institutional mandate, treat canonical records and dependency surfaces as governed constraints, and embed oversight and remedy before any binding effect.

Traceability, accountability, and contestability, so authority can be proven, actions are attributable, outcomes are reconstructable, and decisions remain subject to review, correction, and remedy.

Legal authority, institutional mandate, canonical record basis, governed service logic, attributable execution, operable public interface, and enforceable oversight and remedy, so each outcome can be traced and reviewed under supervision.

Running a process or producing an output does not create legitimacy. Authority derives from law, is carried by designated institutions, and is constrained by authorised procedure and oversight and remedy. Systems can execute tasks, but they cannot own public power.

Only when domesticated into legal authority and institutional mandate, operated under accountable supervision, and constrained by procedures that preserve auditability, controlled change, and remedy operability.

Legal authority and delegation inventory, institutional assignment, canonisation of records and trust anchors, governed service logic and execution controls, public interface readiness, and operational oversight and remedy.

Yes, if legal authority and institutional mandate lead, and contestability and remedy are operable before binding reliance. Parallel delivery increases speed only when jurisdictional safeguards remain enforceable.

Each domain requires legal definition, assigned institutions, canonical record bases where relevant, governed service logic and execution controls, and operable oversight and remedy before digital operation can claim public legitimacy.

By translating assumptions into domestic legal authority, institutional mandates, canonical records, authorised procedures, assurance obligations, and oversight and remedy. Templates can accelerate implementation, but they cannot substitute for lawful delegation and accountable custodianship.

Systems drift into implicit authority, simulate consent or identity, and override public constraints through design defaults. The result is embedded governance without delegation, accountability, or remedy.

As evidence capability that must be governed under public authority. Trust anchors and authoritative references sit within canonical dependencies, while service logic and execution remain controlled through institutional mandate, auditability, and reviewability.

Authority, mandate, records, service logic, execution, public interface, and oversight and remedy operate as one structure. Breakage at any layer undermines enforceability because outcomes can no longer be traced to lawful authority and reviewed under remedy.

By durable legal authority, institutional resilience, and enforceable oversight and remedy over time. Technical capability alone is insufficient because lawful public outcomes require continuous governance capacity.

Oversight and remedy at L7. Without operable contestation and enforceable correction powers, the system forms a closure that excludes law, regardless of technical performance

No component may be relied upon for binding outcomes if it lacks legal authority, assigned institutional mandate, governed record basis, evidence capability, and operable oversight and remedy.

GovStack promotes modular technical building blocks and accelerates delivery. The Seven Layer Model treats DPI as a national trust capability that exists only when legal authority assigns powers, institutions hold mandates, records carry recognised status, and oversight and remedy remain enforceable. The conflict appears when implementation outruns legal authority and custodianship. In that situation, governance becomes configuration, and code begins to function as if it creates legitimacy, even though public powers cannot arise from system design decisions.

GovStack Public Administration Ecosystem Reference Architecture (PAERA) can organise technology domains, but it does not establish legal authority, institutional mandate, record status, or enforceable oversight and remedy. Without that sequence, outcomes may be operational while remaining weakly grounded in lawful accountability.

No. The Seven Layer Model for Digital Public Infrastructure is a governance and legality model. It sequences how public authority becomes a lawful, attributable, reviewable outcome, and it is used to allocate decision rights, evidence duties, accountability, and remedy across public systems. The OSI model is a communications reference model that describes how data moves across network interfaces and protocols. If an implementation discussion is about protocols, encryption, session handling, or message transport, it is in the OSI domain. If the discussion is about authority, mandates, canonical records, issuance, accountability, contestation, and remedy, it is in the Seven Layer Model domain.

The Seven Layer Model for Digital Public Infrastructure is licensed under Creative Commons Attribution ShareAlike 4.0 International.(https://creativecommons.org/licenses/by-sa/4.0/) This licence allows you to copy, share, and adapt the paper for any purpose, including commercial use, provided that you credit the author and publish derivative work under the same licence. When the model informs policy, specifications, architecture, or training material, attribution supports traceability and keeps the framework coherent over time. Recommended attribution Based on the Seven Layer Model for Digital Public Infrastructure by Ott Sarv, licensed under CC BY SA 4.0. Adapted from the Seven Layer Model for Digital Public Infrastructure by Ott Sarv, CC BY SA 4.0.

Ott Sarv is the author of the Seven Layer Model for Digital Public Infrastructure. He is a Independent senior advisor and programme lead with more than 20 years of experience working across more than 40 countries, focused on designing and governing foundational public-sector digital building blocks such as registries, trust services and PKI, secure electronic signatures and organisational seals, high-assurance authentication and single sign-on, policy-controlled data exchange, and digital wallets and consent.  For professional background and contact, his public profile is available at linkedin.com/in/ottsarv.(http://linkedin.com/in/ottsarv)