Digital Sovereignty Target Architecture for Administration X

1. Status and authority

This architecture translates the digital-sovereignty objective of Administration X into binding design and governance requirements. It begins with the public mandate, legal responsibilities and business capabilities, then defines the control, resilience, interoperability and exit conditions that technology must satisfy. It is explicitly not a product-specific reference architecture.

2. Management summary

Administration X MUST retain authority over the control planes on which its ability to act depends. These include in particular:

• authoritative identities for people, organisations, machines and devices;
• authentication and assurance levels;
• business and administrative authorisations;
• cryptographic keys, certificates and trust anchors;
• privileged administration and emergency access;
• network access and data paths;
• authoritative data, registers and metadata;
• integration, API and event architecture;
• security posture, raw logs and forensic evidence;
• software supply and the technology supply chain;
• recovery, crisis operations and exit capability.

Microsoft Entra ID is therefore used solely as a technically necessary, subordinate service directory for Microsoft 365. It is not used for other applications, as a general identity provider, as a trust anchor for on-premises or private-cloud resources, or for VPN, network access, administrative access or high-assurance government contexts.

Third-party cloud services are normally federated directly with the government-controlled identity and access architecture. A temporary connection through Entra ID is outside the target architecture and may be tolerated only after a formal sovereignty impact assessment, explicit acceptance of the residual risk, strict technical containment, a fixed expiry date and an approved migration or exit plan.

3. Government and business model

3.1 Administration X is not a technology corporation

Administration X does not pursue a single commercial purpose. Its unity derives from law, the direction of Government X, the responsibilities of ministries and agencies, and shared principles of lawful public action.

Its central business capability is to perform public tasks lawfully, transparently, effectively, consistently and continuously. Digitalisation is a form of delivering that mandate, not an end in itself.

3.2 Primacy of the business

The following sequence is not permitted:

3.3 Federated public enterprise

Shared foundations are governed across Administration X without removing the statutory and business accountability of ministries and agencies.

4. Binding architecture principles

4.14 Digital sovereignty decision dimensions

5. Overall architecture model

6. Leadership and governance

6.1 Government X

• sets the strategic objectives and the state’s risk appetite;
• decides fundamental questions of sovereignty and dependency;
• ensures political, legal and financial coherence;
• decides strategic deviations of substantial significance.

6.2 Office for Digital Governance and Architecture

The Office for Digital Governance and Architecture leads across Administration X in particular:

• enterprise and business architecture;
• architecture principles and binding target models;
• IAM governance and strategic standard services;
• interoperability, API and data-architecture requirements;
• cloud, sourcing and dependency governance;
• strategic technology and platform decisions;
• deviation and escalation procedures;
• cross-administration architecture assurance.

6.3 Ministries and agencies

• lead their business architecture and digital products;
• own their data, processes and business authorisations;
• carry business and information risk;
• implement the architecture requirements that apply across Administration X.

6.4 ICT service providers

• develop, integrate, operate and monitor;
• advise on technical options;
• are accountable for agreed operational quality;
• deliver within strategic and business guardrails.

6.5 Staged approval

1. Business approval: mandate, legal basis, benefit, process and funding.
2. Data approval: purpose, owner, classification, retention and disclosure.
3. Architecture approval: standards, reuse, integration and dependencies.
4. Sovereignty approval: identity, administration, keys, jurisdiction, continuity and exit.
5. Security approval: risk analysis, protection concept, testing and residual risk.
6. Production approval: operations, support, monitoring, recovery and escalation.

7. Business architecture

7.1 Shared public-sector business capabilities

7.2 Capability ownership

Every shared business capability has a business-leading authority. It owns terminology, information objects, standards, reuse, interfaces and intended outcomes. Leadership of a capability does not automatically fall to the body that operates the current application.

7.3 Product orientation

Every enduring digital public service requires:

• business product accountability;
• defined user and stakeholder groups;
• measurable public value;
• data, risk and security accountability;
• a lifecycle, budget and roadmap;
• an operations, resilience and retirement concept.

8. Information and data architecture

8.1 Data accountability

For every material data object, the following are defined and governed:

• business data owner;
• authoritative source;
• legal purpose and permitted use;
• quality requirements;
• protection and criticality classification;
• retention, archiving and deletion;
• disclosure and access rules;
• metadata, provenance and change history.

8.2 Authoritative sources

8.3 Semantics and data contracts

Administration X maintains common:

• business terms and multilingual terminology;
• unique identifiers;
• reference data and classifications;
• information models and data contracts;
• relationships between public-sector business objects.

8.4 Information lifecycle

Collaboration platforms, personal drives, mailboxes and chat histories are not permanent systems of record. Business-relevant and legally relevant information must be transferred in a controlled manner to the designated records, case-management or archive systems.

8.5 Cryptographic control

Data requiring enhanced protection are secured with keys whose generation, storage, activation, rotation, revocation, recovery and destruction can be controlled and independently audited by Administration X.

9. Identity and trust architecture

9.1 Principle

9.2 Identity domains

• employees and contractors;
• residents and other natural persons;
• companies, organisations and representatives;
• privileged administrators;
• technical accounts and workloads;
• machines, APIs and services;
• device identities;
• automated agents and technical actors.

9.3 Workforce Identity System (WIS)

WIS is the government-controlled reference system for employee and contractor identities and the associated identity lifecycle processes.

WIS governs in particular:

• the global natural-person record;
• joiner, mover, role-change and leaver events;
• controlled identity attributes;
• access-management, recertification and deprovisioning processes;
• provisioning of minimal technical accounts to subordinate services.

9.4 Government Identity and Access Platform (GIAP)

GIAP is the central government-controlled authentication and federation platform for web applications and mobile applications of Administration X.

GIAP provides:

• government-controlled authentication;
• trust and authentication assurance levels;
• multi-factor and hardware-bound methods;
• step-up authentication;
• federation through established standards;
• controlled release of verified identity attributes.

9.5 Public Access Identity Service (PAIS)

PAIS is the central public-service login for natural persons inside and outside traditional administrative boundaries where the relevant service context requires it.

9.6 Business authorisation

Authentication and business authorisation are separate. GIAP and PAIS authenticate and provide verified attributes. Business authorisation remains with the business application, a domain authorisation service or the competent representation and organisation register.

9.7 Administrative identities

Highly privileged administration requires:

• a separate administrative trust domain;
• separate administrative accounts and workstations;
• an isolated management zone;
• minimal, time-limited privileges;
• dual control for especially critical actions;
• complete session and event logging;
• break-glass procedures outside the normal office-automation path;
• no routine internet access from the administration zone.

9.8 Machine and workload identities

• every machine and workload has a unique identity;
• shared, non-attributable service accounts are avoided;
• credentials are short-lived and rotated automatically;
• keys are protected by hardware or trusted platform mechanisms;
• owner, purpose, assurance level and lifecycle are documented;
• deprovisioning is automated.

10. Binding boundary for Microsoft Entra ID

10.1 Core model

Entra ID may contain only those accounts, attributes, groups, service principals and technical objects strictly required for the bounded operation of Microsoft 365. The existence of an Entra object establishes neither a government identity nor a government assurance level nor a business authorisation within Administration X.

10.2 Minimum requirements for a sovereignty deviation

A temporary deviation for connecting a third-party cloud service through Entra ID may be considered only if the decision record answers at least the following questions:

1. Which application and supplier are affected?
2. Why is direct federation with GIAP technically impossible?
3. Which alternatives were examined and why were they rejected?
4. Which people, identity attributes and groups are transferred?
5. Which data, metadata and usage information arise at the supplier?
6. Which jurisdictions, subprocessors and support-access arrangements are relevant?
7. Which authentication and assurance levels are required?
8. Is there any connection to on-premises, VPN, network or administrative resources?
9. How is it ensured that Entra does not govern business roles or permissions?
10. How are joiner, mover, leaver and access-revocation events implemented?
11. How is the deviation technically restricted to this exact service, purpose and user population?
12. Which logs and controls demonstrate compliance?
13. How will the Entra dependency be removed?
14. When does the deviation expire, and what objective conditions prevent automatic renewal?
15. Who accepts the remaining business, security and sovereignty risk?

10.3 Technical enforcement

• Entra Enterprise Applications are denied by default and configured only after approval;
• new app registrations and service principals require a documented owner and purpose;
• admin consent is centrally controlled, while user consent is disabled or severely restricted;
• application and API permissions are minimised and regularly recertified;
• on-premises connectors, Application Proxy, Private Access and tunnel components are technically prevented;
• Entra tokens are not accepted at internal gateways or business applications as a general trust assertion;
• network, VPN and administration systems are not registered as Entra Enterprise Applications;
• tenant configuration is automatically assessed against the binding use matrix;
• deviations are logged, time-limited and reported to the competent governance function.

11. Workplace and device architecture

11.1 Workplace classes

1. Standard workplace: office communication and ordinary business applications.
2. Secure business workplace: enhanced protection needs and a restricted environment.
3. Administrative workplace: exclusively for privileged administration.
4. Mobile workplace: controlled location-independent access.
5. Specialised workplace: operational, laboratory, development, measurement or domain-specific system.
6. Sovereign fallback workplace: reduced, independently operable crisis workplace.

11.2 Device governance

Device management MUST:

• support multiple operating systems and security domains;
• remain separate from the authoritative person identity;
• provide policy and posture information through defined interfaces;
• operate without Entra as the authoritative identity;
• be implementable without Intune as a mandatory platform;
• support controlled certificate and key provisioning;
• be replaceable by alternative products or components.

11.3 Operating-system strategy

Windows remains a supported platform. Linux, macOS, iOS, Android and browser-based workplaces are also supported as regular target platforms.

Administration X MUST in particular:

• provide a productive and supported Linux workplace;
• design business applications to be browser- and platform-independent where appropriate;
• support open document and exchange formats;
• remove operating-system dependencies from business logic;
• maintain a functional fallback workplace for crisis situations.

11.4 Office automation

Office automation is a standard service, not the business-application platform for all of Administration X.

Legally binding or long-term critical administrative processes must not be conducted exclusively in personal mailboxes, chat channels, SharePoint lists, spreadsheets, Power Automate flows or equivalent proprietary workarounds.

12. Network and access architecture

12.1 Function of the network

The network transports communications and enforces technical access rules. It does not govern the natural person, business roles or organisational mandates.

12.2 Zero Trust

Zero Trust means:

• no implicit trust based on location;
• explicit authentication of people, devices and workloads;
• minimal and contextual permissions;
• unambiguous identification of the resource;
• segmentation and restriction of lateral movement;
• continuous monitoring and reassessment.

12.3 Mobile and external access

Traffic to internal resources is not routed through a general supplier cloud without a compelling reason. Device management, person authentication, network transport and business authorisation remain separate functions.

12.4 Strategic network services

• DNS and time services;
• certificate and trust services;
• routing and network-address management;
• internet and partner gateways;
• remote access;
• log transport;
• configuration and management networks;
• crisis and fallback connectivity.

These services must remain available when external cloud-identity or device platforms are disrupted.

13. Application and integration architecture

13.1 Application categories

1. administration-wide foundational and standard services;
2. shared domain services;
3. ministry-level or domain-specific platforms;
4. agency-specific business applications.

13.2 Requirements for business applications

Every business application MUST:

• be assigned to a business capability;
• have a business Product Owner;
• document its data objects and interfaces;
• use GIAP or the designated government IAM service;
• govern business permissions itself or through a domain service;
• be automatically testable, loggable and monitorable;
• have an operations, recovery and retirement path.

13.3 API first and events

APIs have:

• a business owner and API Product Owner;
• a versioned data and service contract;
• defined authentication and authorisation;
• usage limits and logging;
• documentation, support and a lifecycle.

Where appropriate, state changes are published as clearly defined events. Point-to-point integrations and misuse of directories as integration mechanisms are avoided.

13.4 No integration through identity groups

13.5 Low-code

Low-code is permissible for prototypes, limited tools and clearly controlled internal applications. Business-critical solutions nevertheless require normal product, data, testing, release, security, operations and exit accountability.

14. Cloud and infrastructure architecture

14.1 Cloud is a delivery model

Possible placements include:

• traditional government infrastructure;
• Government X Private Cloud;
• Government X Secure Private Cloud;
• controlled domestic partner infrastructure;
• public cloud in a domestic region;
• international public cloud;
• software as a service;
• edge and specialised infrastructure.

14.2 Placement decision

Placement is determined by:

• legal basis and permitted processing;
• protection needs and criticality;
• identity, key and administration model;
• jurisdiction and possible extraterritorial access;
• supply chain and subcontractors;
• continuity and recovery capability;
• portability and exit;
• whole-lifecycle economics.

14.3 Strategic control planes

The following normally remain under government control:

• authoritative identities and authentication;
• central PKI and strategic key management;
• privileged administration;
• security operations and the central security picture;
• network and access-control architecture;
• crisis communications and restart coordination;
• authoritative registers of special public significance.

14.4 Government X Cloud

Government X Cloud is designed as a shared sourcing and infrastructure architecture, not as a blanket justification for moving all services into public clouds.

It MUST enable:

• multiple technical stacks and suppliers;
• a private cloud without dependency on a public-cloud control plane;
• government-controlled identities, keys and administration;
• standardised portability;
• operational competence within Administration X;
• a defined autonomous operating period;
• tested fallback and restart paths.

14.5 A tenant is not an operating model

A cloud tenant is a technical security and operations container. It is not a government identity, a business organisation, an overarching authorisation model or a source of data ownership.

15. Security architecture

15.1 Defence in depth

Protection layers include at least:

• identity and authentication;
• endpoint and local keys;
• network and segmentation;
• application and business authorisation;
• data and cryptography;
• administration and segregation of duties;
• monitoring and incident response;
• people, processes and supply chain;
• backup and recovery.

15.2 Supplier-independent security picture

Administration X requires:

• access to raw logs and security events;
• cross-supplier correlation;
• its own detection and response rules;
• threat intelligence, forensics and cyber hunting;
• secured long-term evidence and timestamps;
• independent capacity for situational assessment.

15.3 Privileged access management

• separate accounts and workstations;
• time-limited and approved permissions;
• complete attribution and logging;
• regular recertification;
• no administration from ordinary office workstations;
• independent emergency access.

15.4 Software supply chain

Strategic software requires:

• traceable provenance and a software bill of materials;
• signed and verifiable artefacts;
• controlled build and deployment pipelines;
• vulnerability and dependency management;
• governed update sources and staged distribution;
• emergency procedures for compromised supply chains;
• secure decommissioning and data sanitisation.

15.5 Cryptographic agility

• an inventory of algorithms and keys in use;
• central cryptographic policies;
• replaceable HSM and key-management components;
• flexible certificate profiles;
• preparation for post-quantum migration;
• controlled parallel and transition mechanisms.

16. Operations, resilience and crisis

16.1 Clear accountability

Every service has at least:

• business product accountability;
• service accountability;
• technical operations accountability;
• security and data accountability;
• supplier accountability;
• documented deputies and escalation routes.

16.2 Criticality classes

The actual classification is based on a business-impact analysis. For every service, MTPD, RTO, RPO, minimum functional scope, autonomous operating period, dependencies and restart sequence are defined.

16.3 Degraded operation

Critical systems provide where necessary:

• alternative or local trust services;
• prioritised user groups;
• reduced data sets;
• read operation without full write capability;
• queues and later synchronisation;
• manual fallback and approval procedures;
• fallback workplaces and emergency communications.

16.4 Backup and recovery

• separate and immutable backup layers;
• offline or logically isolated copies;
• separate administrative privileges;
• regular full restoration tests;
• restart without active assistance from the primary supplier;
• backup of configurations, keys and dependencies.

16.5 Mandatory crisis scenarios

• failure of Microsoft 365;
• failure or compromise of the Entra tenant;
• failure of Intune or another device platform;
• failure of international public-cloud services;
• failure of a government data centre;
• failure of international networks or external DNS dependencies;
• a compromised software supply chain;
• unavailable external supplier support;
• contract termination or service restriction;
• restart from immutable backups.

17. Sourcing, procurement and supply chain

17.1 Critical internal capabilities

The following must not be fully outsourced:

• enterprise and business architecture;
• IAM governance;
• key and trust management;
• strategic security direction;
• data accountability and semantics;
• end-to-end integration knowledge;
• supplier and dependency governance;
• crisis, recovery and exit competence.

17.2 Supplier as a dependency domain

17.3 Procurement criteria

• functionality and total cost;
• strategic dependency and market concentration;
• access to data, metadata and keys;
• administration model and jurisdiction;
• interoperability and open standards;
• source availability and verifiability;
• supply-chain transparency;
• continuity, portability and exit cost;
• transfer of competence to Administration X.

17.4 Contractual requirements

• complete data-export rights and defined formats;
• access to interfaces and protocols;
• transparency of subcontractors and locations;
• audit, inspection and notification obligations;
• vulnerability and incident handling;
• exit support and calculable exit prices;
• transfer of competence and documentation;
• rules for keys, certificates and deletion;
• continuity of critical services during transition.

17.5 Exit capability

An exit is credible only when it has been demonstrated that:

• data, metadata and permission relationships are exportable;
• alternative identity and access paths exist;
• a replacement platform is available or can realistically be built;
• knowledge, source code, configurations and documentation are available;
• operations can continue during migration;
• the migration has been tested in practice.

18. Artificial intelligence and agents

18.1 AI remains a tool

AI can assist with:

• research, classification and translation;
• summarisation and pattern recognition;
• decision preparation;
• process support and user interaction.

AI does not replace:

• statutory competence;
• accountability of natural persons;
• duties to give reasons and maintain records;
• business and legal review;
• democratic and administrative accountability.

18.2 No hidden AI platform lock-in

AI services must not result in:

• all administrative data being transferred into a supplier graph;
• government permissions being represented only in a supplier platform;
• prompts and content being processed outside controlled environments without governance;
• business logic existing exclusively in proprietary agent platforms;
• one supplier becoming the sole gateway to knowledge, data and work processes.

18.3 Agent identities

An AI agent has neither a PAIS account nor a natural-person identity. It acts as a uniquely identifiable technical actor within a bounded, logged and revocable mandate.

Machine actions must:

• be attributable to an accountable body and a defined mandate;
• be technically and uniquely identified;
• have minimal and time-limited permissions;
• be fully logged and reviewable;
• be stoppable and reversible where the business process permits.

19. Transformation path

Phase 1: Establish transparency

• create inventories of applications, services, data and identities;
• record Microsoft dependencies as a shared platform domain;
• document data flows, jurisdictions and key accountability;
• identify critical suppliers, control planes and single points of failure;
• assess existing exit and crisis capability.

Phase 2: Stop further consolidation

• no new business applications with Entra as identity provider;
• no Entra or Conditional Access dependency for on-premises systems or VPN;
• no new Microsoft Tunnel or Application Proxy dependencies;
• no migration of business roles into Entra or M365 groups;
• no new third-party cloud connections through Entra without a formally approved, time-limited sovereignty deviation;
• no critical processes exclusively in Power Platform or M365.

Phase 3: Strengthen sovereign control planes

• develop GIAP, WIS and PAIS further;
• establish government administrative identities and management zones;
• strengthen PKI, key management and machine identities;
• establish multi-platform device management;
• expand supplier-independent security intelligence and the API platform;
• provide crisis workplaces and autonomous infrastructure.

Phase 4: Decouple applications

• remove Entra connections from business applications;
• return authentication to GIAP;
• remove business roles from supplier groups;
• document data models and APIs;
• turn M365 shadow applications into governed business products;
• test exit and restart paths in practice.

Phase 5: Diversify the workplace

• provide a productive Linux workplace;
• test alternative office automation and open formats;
• increase browser and platform capability of business applications;
• decouple mobile access from Entra, Intune and Microsoft Application Proxy;
• create independent endpoint and device-posture signals.

Phase 6: Exercise failure and exit

• M365 and Entra outage;
• tenant compromise;
• public-cloud and supplier outage;
• compromised software supply chain;
• restart without external support;
• migration of a critical service to an alternative platform.

19.1 Measures

• share of business applications using GIAP or the competent government IAM service;
• number of Entra integrations outside M365;
• number, age and residual risk of active sovereignty deviations;
• share of critical services with tested degraded operation;
• share of critical services with a practically validated exit;
• share of multi-platform business applications;
• productive use of alternative workplaces;
• share of automatically governed machine identities;
• time between departure and complete access revocation;
• number of suppliers that simultaneously control several strategic control planes;
• recovery time achieved in realistic exercises.

20. Binding red lines

1. No authoritative person identity in Entra ID.
2. No primary authentication of business applications by Entra ID.
3. No Entra single sign-on for high-assurance contexts equivalent to LoA3.
4. No general dependency on Intune for access to business applications.
5. No binding of on-premises, private-cloud or VPN access to Conditional Access.
6. No publication of internal applications through Entra Application Proxy.
7. No Microsoft Tunnel to internal resources.
8. No flow of authoritative identity or permission data from Entra into government systems.
9. No password-hash synchronisation or cloud-led primary authentication.
10. No business authorisation through Entra, M365 or Intune groups.
11. No authoritative administrative trust domain in Entra.
12. No sole security truth in Defender or any other single supplier.
13. No legally binding records management exclusively in Teams, SharePoint or OneDrive.
14. No critical business processes exclusively in Power Platform.
15. No administration-wide integration architecture based on Microsoft Graph.
16. No third-party cloud connection through Entra without a formally approved, time-limited sovereignty deviation.
17. No new strategic supplier dependency without sovereignty, resilience and exit assessment.
18. No production launch of a critical service without tested recovery.
19. No sovereignty deviation without an expiry date, accountable owner, explicit risk acceptance and decommissioning plan.
20. No supplier becomes an irreplaceable identity, device, access, data, security and administration authority at the same time.

21. Target state

In the target state, Administration X has a shared, federated business and enterprise architecture.

• The public mandate leads digital solutions.
• The Office for Digital Governance and Architecture leads enterprise architecture and strategic standard services across Administration X.
• Ministries and agencies lead domain architecture, processes, data and products.
• ICT service providers implement and operate within binding guardrails.
• GIAP, WIS and PAIS form the government-controlled identity and trust foundation.
• Business applications connect through open standards.
• Business permissions remain in competent government systems.
• The workplace landscape is genuinely multi-platform.
• Mobile and external access uses direct, controlled data paths.
• Cloud services are placed according to protection needs, criticality and sovereignty impact.
• Security information can be assessed independently of individual suppliers.
• Cryptographic keys and privileged administration remain under government control.
• Entra ID remains limited to Microsoft 365.
• Third-party clouds are federated directly; any temporary Entra connection is explicitly treated as a deviation from the target architecture and is subject to expiry and exit.
• A Microsoft outage or exit may reduce convenience but does not disable the state.

22. Sources and foundations

The following are generic foundations and example public reference models. The specific red lines and use matrix are normative architecture decisions derived from these foundations and the sovereignty objective of Administration X.

1. Administration X, Government IAM Strategy. Internal foundation for government-controlled identities and authentication, replacement of cloud-led identity models, and federation of cloud and SaaS services through established protocols.
2. Administration X, Digital Administration Strategy. Internal foundation for connected administration, interoperability, data orientation, platforms, security, sovereignty and coordinated transformation.
3. Administration X, Shared and Foundational Services Policy. Generic internal foundation for strategic leadership, portfolio governance, requirements, quality, interoperability and service-governance roles.
4. Administration X, API Architecture. Internal foundation for standardised API metadata, API catalogues, product accountability, interoperability and versioned interfaces.
5. Administration X, Digital Government Act. Generic legal foundation for digital public services, reuse, interoperability and publication or sharing of government-developed software where applicable.
6. NIST SP 800-207, Zero Trust Architecture. Describes Zero Trust as an enterprise architecture and distinguishes the Policy Engine, Policy Administrator and Policy Enforcement Point. Open NIST SP 800-207
7. NIST SP 800-161 Revision 1, Cybersecurity Supply Chain Risk Management Practices. Foundation for enterprise-wide, lifecycle-based management of supply-chain and supplier risks. Open NIST SP 800-161r1
8. European Commission, Cloud Sovereignty Framework. A multidimensional model for assessing strategic, legal, operational, technological and supply-chain sovereignty. Open the Cloud Sovereignty Framework
9. Microsoft, Conditional Access. Describes Microsoft’s policy engine combining identity, device, risk, location and application signals. Open Microsoft documentation
10. Microsoft, Conditional Access for VPN. Documents integration of cloud-based policy and device-compliance signals with VPN access. Open VPN documentation
11. Microsoft, Entra Application Proxy. Documents remote access to internal applications through Entra ID, a cloud proxy service and private network connectors. Open Application Proxy documentation
12. Microsoft, Microsoft Tunnel for Intune. Documents VPN access to on-premises resources coupled to Intune, Entra, modern authentication and Conditional Access. Open Microsoft Tunnel documentation
13. Microsoft, Intune and Conditional Access. Documents use of device state determined by Intune as an access condition in Entra Conditional Access. Open Intune integration documentation