# Defra architecture

> Architecture handrails, guardrails and governance for Defra digital, data and technology - for internal product and platform teams and delivery partners.

Version in force: 0.3.0. Every page has a Markdown copy at its address plus `index.md`.
Each page's maturity is prototype, draft or published. Treat prototype and draft content as work in progress,
not agreed policy. Guardrail ids such as GR-HOST-01 are stable and can be cited.

## Data

- [guardrails.json](https://defra.github.io/architecture/guardrails.json): Every guardrail and principle: id, level, statement, why, how to meet it, evidence by phase, status
- [nfrs.json](https://defra.github.io/architecture/nfrs.json): Service tiers and the non-functional requirements catalogue
- [capabilities.json](https://defra.github.io/architecture/capabilities.json): Business capabilities and the technology capability model (TBM level 1 and level 2)
- [pages.json](https://defra.github.io/architecture/pages.json): Every page with its section, maturity and Markdown copy

## Home

- [Defra architecture](https://defra.github.io/architecture/index.md) (published)
- [Approval status](https://defra.github.io/architecture/about/approval-status/index.md) (published): Which parts of this site are agreed, who approved them and when, and which are still draft. Use it to judge how much weight to put on a page.
- [Developing architecture at Defra](https://defra.github.io/architecture/about/architecture-profession/index.md) (draft): How architects at Defra learn, connect and grow, and how anyone interested in architecture can get involved. This is an early version: we will add to it as the profession develops.
- [What's new](https://defra.github.io/architecture/about/changelog/index.md) (published): Significant changes to guardrails, capabilities and governance. Minor wording changes are visible in the commit history.
- [Working with us as a delivery partner](https://defra.github.io/architecture/about/delivery-partners/index.md) (published): Much of Defra's digital work is delivered with partners. This page sets out what you can expect from us, and what we expect from you, so we can work as one team.
- [Moving to the DEFRA GitHub organisation](https://defra.github.io/architecture/about/moving-to-defra/index.md) (published): The site and its repository moved from a personal fork, howellsr/architecture, to DEFRA/architecture, published at defra.github.io/architecture. This page records how, and what keeps old links working.
- [Open questions](https://defra.github.io/architecture/about/open-questions/index.md) (published): Facts this site needs but that are not yet confirmed - names, contacts, lead times and approvals. We would rather show a gap than guess.
- [Releases and versions](https://defra.github.io/architecture/about/releases/index.md) (published): Which version of the guardrails is in force, what changed in each release, and how to cite a fixed version in a contract or assessment.
- [Roadmap](https://defra.github.io/architecture/about/roadmap/index.md) (published): What we are working on, what comes next and what we are considering. This site is in alpha: we are developing it in the open and it will change as we learn from the teams and partners who use it.
- [The architecture team](https://defra.github.io/architecture/about/team/index.md) (draft): We help Defra make good technology decisions quickly. We set direction, publish guardrails and handrails, run governance, and work alongside delivery teams.
- [Using this site](https://defra.github.io/architecture/about/using-this-site/index.md) (published): How to find what you need, depending on who you are and what you are doing.
- [Contracting with this site](https://defra.github.io/architecture/partners/contracting/index.md) (published): How to reference the guardrails in a statement of requirements or statement of work, so buyers and suppliers share one clear, stable baseline.
- [Handover and exit](https://defra.github.io/architecture/partners/handover-and-exit/index.md) (published): What "done" means when a partner hands a service to Defra or to another supplier, so the next team can run and change it without the people who built it.
- [Mobilisation checklist](https://defra.github.io/architecture/partners/mobilisation/index.md) (published): What a delivery partner needs in place to start work on a Defra engagement, and who to meet in the first week. Start early: some access takes weeks.
- [Working with other suppliers](https://defra.github.io/architecture/partners/multi-supplier/index.md) (published): Many Defra services are built by more than one team, often from different companies. These rules of the road stop integrations, incidents and environments falling between the gaps.

## Other

- [Decisions about this site](https://defra.github.io/architecture/adr/index.md) (published): Architecture decision records (ADRs) for this site and repository. We follow our own guardrail GR-DEV-09.
- [0001. Build the site with MkDocs Material and generate lists with hooks](https://defra.github.io/architecture/adr/0001-mkdocs-material-with-hooks/index.md) (published)
- [0002. Keep guardrail metadata in each page's front matter](https://defra.github.io/architecture/adr/0002-guardrail-metadata-in-front-matter/index.md) (published)
- [0003. Release versions as tags and PDFs, not versioned URLs](https://defra.github.io/architecture/adr/0003-no-versioned-urls/index.md) (published)
- [0004. Keep Must guardrails to what is required](https://defra.github.io/architecture/adr/0004-musts-only-where-required/index.md) (published)
- [0005. Record enterprise decisions in a SharePoint register, not in this repository](https://defra.github.io/architecture/adr/0005-enterprise-decisions-in-sharepoint/index.md) (published)
- [0006. Move the site to DEFRA/architecture](https://defra.github.io/architecture/adr/0006-move-to-defra-github/index.md) (published)
- [Contribute](https://defra.github.io/architecture/contribute/index.md) (published): This site is built in the open and improves when the people who use it change it. Defra staff and delivery partners are equally welcome to contribute.
- [Content style](https://defra.github.io/architecture/contribute/content-style/index.md) (draft): How we write for this site, so every page reads the same way and busy delivery teams find what they need quickly. It builds on the GOV.UK style guide; it only adds what is specific to this site.
- [Site design](https://defra.github.io/architecture/contribute/site-design/index.md) (draft): How this site is built and why it looks and behaves the way it does - for maintainers changing the theme, a template or a generated page. To change the words, see content style instead.
- [Updating the Defra architecture site: a guide for the team](https://defra.github.io/architecture/contribute/team-guide/index.md) (draft): Start here if you are new to updating this site. It explains how the site is built, the rules every change follows, which file to edit for each kind of change and how a change gets published.
- [Where things live](https://defra.github.io/architecture/contribute/where-things-live/index.md) (draft): Where to find the guidance, where to suggest a change and where work is tracked - and how this site and the Defra Digital Service Manual share the work, so each fact has one home.
- [Reference architecture](https://defra.github.io/architecture/handrail/reference-architecture/index.md) (draft): A layered view of Defra's technology - from the services users see down to the shared platforms and infrastructure they run on - is planned for a future iteration of this site.
- [Standards and links](https://defra.github.io/architecture/standards/index.md) (published): The government and Defra standards this site builds on. Our guardrails apply these to Defra's context - they do not replace them.

## Topics

- [Enterprise data architecture](https://defra.github.io/architecture/data/index.md) (published): Defra runs on data - from river levels and disease surveillance to land parcels and farm payments. Enterprise data architecture helps that data be found, trusted, joined up and reused.
- [Data standards](https://defra.github.io/architecture/data/data-standards/index.md) (published): The standards that make Defra data consistent, joinable and reusable. Use these by default - see guardrail GR-DATA-03.
- [Defra on a page](https://defra.github.io/architecture/data/defra-on-a-page/index.md) (published)
- [Enterprise security architecture](https://defra.github.io/architecture/security/index.md) (published): Security is part of how we design and deliver, not a gate at the end. Enterprise security architecture helps teams build secure services by default and manage risk openly when they cannot.
- [Managing security exceptions](https://defra.github.io/architecture/security/managing-exceptions/index.md) (draft): Sometimes a security control cannot be met - because of a legacy dependency, a supplier constraint or a delivery deadline. That is a risk decision, and it must be made explicitly, by the right person, for a limited time.
- [Secure by Design](https://defra.github.io/architecture/security/secure-by-design/index.md) (published): Secure by Design is the government's approach to building security into digital services from the start and throughout their life. This page is the architecture view of how Defra teams apply it. The Defra Security team owns Defra's security policies and the Secure by Design lifecycle requirements.
- [Threat modelling](https://defra.github.io/architecture/security/threat-modelling/index.md) (published): Threat modelling is a structured conversation about what could go wrong with a service and what to do about it. Done by the team, early and often, it is the most cost-effective security activity there is.

## Deliver a service

- [Deliver a service](https://defra.github.io/architecture/deliver/index.md) (prototype): What architecture your team needs at each stage of delivery: the guardrails that apply, the artefacts to produce, who to talk to and the evidence to bring to an assessment.
- [Alpha](https://defra.github.io/architecture/deliver/alpha/index.md) (prototype): Alpha is where you test the riskiest design assumptions. Most of the architecture decisions that are expensive to reverse are made here, so this is the phase that needs the most architecture attention.
- [Beta](https://defra.github.io/architecture/deliver/beta/index.md) (prototype): Beta is where you build the real service and prove it is secure, reliable and ready to run. The architecture job is to keep the design and the evidence in step with what you build.
- [Discovery](https://defra.github.io/architecture/deliver/discovery/index.md) (prototype): Discovery is about understanding the problem, not choosing technology. The architecture job is to find what already exists, spot constraints early and avoid committing to a solution too soon.
- [Check your repository automatically](https://defra.github.io/architecture/deliver/guardrail-check/index.md) (prototype): A GitHub Action that checks a repository against the guardrails a tool can check, and writes a report that names each guardrail. Add it on day one and fix the gaps before anyone has to ask.
- [Live](https://defra.github.io/architecture/deliver/live/index.md) (prototype): A live service is never finished. The architecture job is to keep it secure, supported and affordable, and to keep the evidence current so the next team can change it safely.
- [Getting onto Defra platforms](https://defra.github.io/architecture/deliver/platforms/index.md) (prototype): The shared platforms most Defra services use, what each gives you, and how to get access. Using them is usually faster, cheaper and safer than building your own.
- [Retire a service](https://defra.github.io/architecture/deliver/retire/index.md) (prototype): Retiring a service well protects users, data and money. Plan it as carefully as a launch.
- [Significant change](https://defra.github.io/architecture/deliver/significant-change/index.md) (prototype): A significant change is one that changes the service's architecture, risks or users enough that the evidence from its last assessment no longer holds. Treat it as a small piece of delivery with its own design, evidence and governance.
- [Working with architects](https://defra.github.io/architecture/deliver/working-with-architects/index.md) (prototype): For service designers, interaction designers, content designers and user researchers: when to involve an architect, what to bring, and what you can expect in return.
- [Alpha](https://defra.github.io/architecture/deliver/checklists/alpha/index.md) (prototype): The architecture evidence for alpha, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
- [Beta](https://defra.github.io/architecture/deliver/checklists/beta/index.md) (prototype): The architecture evidence for beta, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
- [Discovery](https://defra.github.io/architecture/deliver/checklists/discovery/index.md) (prototype): The architecture evidence for discovery, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
- [Live](https://defra.github.io/architecture/deliver/checklists/live/index.md) (prototype): The architecture evidence for live, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
- [Retirement](https://defra.github.io/architecture/deliver/checklists/retire/index.md) (prototype): The architecture evidence for retiring a service, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
- [Significant change](https://defra.github.io/architecture/deliver/checklists/significant-change/index.md) (prototype): The architecture evidence for significant change, as a checklist you can work through or print. Built from the guardrail metadata each time the site is published.
- [By role](https://defra.github.io/architecture/deliver/roles/index.md) (prototype): Every guardrail names the roles that lead it. Find the guardrails for your role, what to show in each phase, and when to work with an architect.
- [Content designer](https://defra.github.io/architecture/deliver/roles/content-designer/index.md) (prototype): The guardrails a content designer leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Data architect](https://defra.github.io/architecture/deliver/roles/data-architect/index.md) (prototype): The guardrails a data architect leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Delivery manager](https://defra.github.io/architecture/deliver/roles/delivery-manager/index.md) (prototype): The guardrails a delivery manager leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Developer](https://defra.github.io/architecture/deliver/roles/developer/index.md) (prototype): The guardrails a developer leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Interaction designer](https://defra.github.io/architecture/deliver/roles/interaction-designer/index.md) (prototype): The guardrails an interaction designer leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Performance analyst](https://defra.github.io/architecture/deliver/roles/performance-analyst/index.md) (prototype): The guardrails a performance analyst leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Product manager](https://defra.github.io/architecture/deliver/roles/product-manager/index.md) (prototype): The guardrails a product manager leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Security architect](https://defra.github.io/architecture/deliver/roles/security-architect/index.md) (prototype): The guardrails a security architect leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Service designer](https://defra.github.io/architecture/deliver/roles/service-designer/index.md) (prototype): The guardrails a service designer leads, what to show in each phase, the patterns that help and when to work with an architect.
- [Technical architect](https://defra.github.io/architecture/deliver/roles/technical-architect/index.md) (prototype): The guardrails a technical architect leads, what to show in each phase, the patterns that help and when to work with an architect.
- [User researcher](https://defra.github.io/architecture/deliver/roles/user-researcher/index.md) (prototype): The guardrails an user researcher leads, what to show in each phase, the patterns that help and when to work with an architect.

## Governance

- [Governance](https://defra.github.io/architecture/governance/index.md) (published): Light-touch, proportionate and as delegated as possible. Our governance exists to help teams make good decisions quickly, not to slow them down.
- [Architecture decision records](https://defra.github.io/architecture/governance/architecture-decision-records/index.md) (published): An architecture decision record (ADR) captures one significant decision, its context and its consequences. ADRs are how we make governance light: a decision that is written down well rarely needs a meeting.
- [Check a decision](https://defra.github.io/architecture/governance/decision-check/index.md) (published): Seven questions to find out whether your team can make a decision itself, needs targeted advice, or should take it to a design authority. It takes about two minutes and gives you a draft decision record to keep.
- [Exception register](https://defra.github.io/architecture/governance/exception-register/index.md) (published): Approved exceptions to guardrails: which guardrail, for which service, who owns it and when it ends. Publishing them shows where guardrails do not fit, and keeps exceptions time-limited.
- [Exceptions to guardrails](https://defra.github.io/architecture/governance/exceptions/index.md) (draft): Guardrails are defaults, and sometimes the right answer is different. The exception process gives you a quick, recorded decision - and tells us when a guardrail needs to change.
- [Guardrails health](https://defra.github.io/architecture/governance/guardrails-health/index.md) (published): How well the guardrails are working: where teams need exceptions, which exceptions end soon, and which guardrails are due for change. Reviewed every quarter.
- [Solution design authorities](https://defra.github.io/architecture/governance/solution-design-authorities/index.md) (draft): SDAs are where most architecture decisions are assured. They sit close to delivery, within delivery groups or portfolios, with authority delegated from the TDA. In an SDA, the principal architect is accountable for decisions.
- [Technical Design Authority](https://defra.github.io/architecture/governance/tda/index.md) (draft): The TDA is Defra's technical decision-making authority. It agrees roadmaps, grants authority to solution design authorities, and reviews cross-cutting and novel work and exceptions to the guardrails. It is a peer review that helps teams get to a good design - not an exam.
- [Technology Governance Board](https://defra.github.io/architecture/governance/tgb/index.md) (draft): The TGB sets Defra's technology direction. It approves strategies, standards and guardrails, and the investment that shapes Defra's technology estate.
- [Which route do I take?](https://defra.github.io/architecture/governance/triage/index.md) (published): Answer five questions to find the lightest governance route that fits your work.
- [Templates](https://defra.github.io/architecture/governance/templates/index.md) (published): Lightweight templates for the most common architecture artefacts. Copy them into your repository and adapt as needed.
- [Architecture decision record](https://defra.github.io/architecture/governance/templates/adr/index.md) (published)
- [Guardrail exception request](https://defra.github.io/architecture/governance/templates/exception-request/index.md) (published)
- [TDA submission](https://defra.github.io/architecture/governance/templates/tda-submission/index.md) (published)
- [Threat model](https://defra.github.io/architecture/governance/templates/threat-model/index.md) (published)

## Rules

- [Guardrails](https://defra.github.io/architecture/guardrails/index.md) (published): Guardrails are opinionated, good-practice defaults for designing, building and running services in Defra. They exist so teams can make good decisions quickly, without waiting for permission.
- [Artificial intelligence](https://defra.github.io/architecture/guardrails/ai/index.md) (published): AI can help Defra do more with less - from classifying species in images to drafting responses. These guardrails help teams use it safely, lawfully and transparently.
- [APIs and integration](https://defra.github.io/architecture/guardrails/apis-and-integration/index.md) (published): How services talk to each other and to partners. Good integration lets us reuse capabilities and change one part of Defra without breaking another.
- [Choosing technology](https://defra.github.io/architecture/guardrails/choosing-technology/index.md) (published): How to decide whether to reuse, buy or build - and how to avoid being stuck with the choice.
- [Data](https://defra.github.io/architecture/guardrails/data/index.md) (published): Defra's science, regulation and payments all depend on trusted data. These guardrails make sure the data each service creates is an asset for the whole department.
- [Digital first (draft)](https://defra.github.io/architecture/guardrails/digital-first/index.md) (published): Design whole services around users, digital by default, without leaving behind people who cannot use them online. These draft guardrails describe what that means for architecture.
- [Field working and devices (draft)](https://defra.github.io/architecture/guardrails/field-working-and-devices/index.md) (published): Many Defra staff and partners work on farms, at ports, on rivers and at sea. These draft guardrails make sure the tools they use work where they work, and keep Defra data safe on the move.
- [Front end and accessibility](https://defra.github.io/architecture/guardrails/front-end-and-accessibility/index.md) (published): Defra services should look like government, work for everyone and work on any device.
- [Hosting and platforms](https://defra.github.io/architecture/guardrails/hosting-and-platforms/index.md) (published): Where and how services run. Use the paved road so your team can focus on users rather than infrastructure.
- [Identity and access](https://defra.github.io/architecture/guardrails/identity-and-access/index.md) (published): Who users are and what they are allowed to do. Getting this right once, centrally, is safer and simpler for everyone.
- [Guardrail library](https://defra.github.io/architecture/guardrails/library/index.md) (published): Every guardrail in one place. Search by keyword or id, filter by area, phase, role, status or level, and select a guardrail to read why it exists and how to meet it.
- [Observability and operations](https://defra.github.io/architecture/guardrails/observability-and-operations/index.md) (published): Services live for years. These guardrails make sure they can be run, supported and improved by people who did not build them.
- [Open source and working in the open](https://defra.github.io/architecture/guardrails/open-source/index.md) (published): We code in the open and share what we learn. It improves quality, makes reuse easy and lets partners see how we work before they work with us.
- [Products and platforms (draft)](https://defra.github.io/architecture/guardrails/products-and-platforms/index.md) (published): Defra builds and runs technology as long-lived products on shared platforms, not as one-off projects. These draft guardrails describe what that means for teams.
- [Security](https://defra.github.io/architecture/guardrails/security/index.md) (published): Security guardrails for every Defra service. They put the government Secure by Design approach into practice.
- [Software development](https://defra.github.io/architecture/guardrails/software-development/index.md) (published): How we write, test and ship code so that any Defra team, or any partner, can pick it up and run with it.
- [Sustainability](https://defra.github.io/architecture/guardrails/sustainability/index.md) (published): Defra leads the Greening Government ICT and Digital Services strategy. Our own services should show what good looks like.
- [Non-functional requirements](https://defra.github.io/architecture/nfrs/index.md) (published)
- [NFR catalogue](https://defra.github.io/architecture/nfrs/catalogue/index.md) (draft): Defra's standard non-functional requirements. Start from these rather than writing your own, so services are consistent and assessors know what good looks like.
- [Service tiers](https://defra.github.io/architecture/nfrs/service-tiers/index.md) (draft): Not every service needs the same level of availability and support. A service tier sets proportionate targets, so critical services get the resilience they need and smaller services are not over-engineered.
- [Writing good NFRs](https://defra.github.io/architecture/nfrs/writing-nfrs/index.md) (published): A good NFR is specific, measurable and testable. If you cannot write a test for it, it is not finished.
- [Principles](https://defra.github.io/architecture/principles/index.md) (published): How Defra decides. The DDTS doctrine sets the non-negotiables. The architecture principles apply them to technology change. The guardrails turn both into practical defaults for delivery teams.
- [Architecture principles](https://defra.github.io/architecture/principles/architecture-principles/index.md) (published): Defra's eight Strategic Architecture Principles. They make decisions consistent, reduce complexity and stop change fragmenting across services. Use them to govern technology change across Defra so that it supports Defra's strategic goals.
- [DDTS doctrine](https://defra.github.io/architecture/principles/doctrine/index.md) (draft): Seven non-negotiables set by the Chief Digital and Information Officer for Defra's Digital, Data and Technology Services (DDTS). They give everyone a common way of thinking and a consistent basis for decisions, so people can decide well without escalating every choice.

## Reuse

- [The architecture handrail](https://defra.github.io/architecture/handrail/index.md) (published): Guardrails tell you where the edges are. The handrail is something to hold on to: a shared map of what Defra does, the technology that enables it, and what already exists that you can reuse.
- [Business capabilities](https://defra.github.io/architecture/handrail/business-capabilities/index.md) (published): Business capabilities describe what Defra does - not how, not who, and not with which system. They are the stable backbone that strategy, investment and technology hang from.
- [Capability mapping](https://defra.github.io/architecture/handrail/capability-mapping/index.md) (published): How Defra's business capabilities depend on technology capabilities. Use it to find what your service will probably need, and to see where shared investment pays off most.
- [Services and capabilities](https://defra.github.io/architecture/handrail/services-and-capabilities/index.md) (draft): What we mean by a service, a product, a capability and related words, using Defra's service taxonomy, and how the taxonomy connects to the architecture handrail.
- [Technology capabilities](https://defra.github.io/architecture/handrail/technology-capabilities/index.md) (draft): Technology capabilities describe what technology must do to enable Defra's business capabilities. Defra's model is aligned to Technology Business Management (TBM): 6 level 1 areas, each with its level 2 capabilities.
- [Architecture patterns](https://defra.github.io/architecture/patterns/index.md) (published): Patterns are reusable shapes for building Defra services. They are early, exploratory work: starting points for discussion, not agreed designs.
- [Acting on behalf](https://defra.github.io/architecture/patterns/acting-on-behalf/index.md) (published): Separate who someone is from what they are allowed to do, so farmers, businesses, agents and land managers can act for the organisations and holdings they represent - and nobody else.
- [Asynchronous submission](https://defra.github.io/architecture/patterns/async-submission/index.md) (published): Accept a user's submission straight away, store it safely, and hand it to other systems through events - so a slow or broken back office never stops a user from applying.
- [Authoritative source](https://defra.github.io/architecture/patterns/authoritative-source/index.md) (published): Use the record Defra already holds, by reference, instead of keeping your own copy that slowly drifts out of date.
- [File upload and scanning](https://defra.github.io/architecture/patterns/file-upload/index.md) (published): Treat every uploaded file as hostile until it has been scanned. Keep it apart from clean files, and only let staff and systems open files that have passed.
- [Publishing open data](https://defra.github.io/architecture/patterns/open-data-publishing/index.md) (published): Publish data once, in open formats, with metadata that lets people find it, understand it and trust it - and an automated pipeline that keeps it current.
- [Service patterns](https://defra.github.io/architecture/patterns/service/index.md) (draft): Service patterns are early, exploratory starting shapes for common kinds of Defra service. Each shows the main building blocks of a whole service and how they connect.
- [Data and analytics](https://defra.github.io/architecture/patterns/service/data-and-analytics/index.md) (draft): An exploratory starting shape for collecting, managing, analysing and publishing evidence and environmental data.
- [Field inspection](https://defra.github.io/architecture/patterns/service/field-inspection/index.md) (draft): A proposed starting shape for services where staff plan, carry out and record inspections, surveys and sampling in the field - often with no mobile signal.
- [Grants and schemes](https://defra.github.io/architecture/patterns/service/grants/index.md) (draft): A proposed starting shape for configuring schemes, taking applications, managing agreements, checking claims and making payments.
- [Incident response](https://defra.github.io/architecture/patterns/service/incident-response/index.md) (draft): A proposed starting shape for detecting, coordinating and reporting on incidents such as animal and plant disease outbreaks, floods and pollution events.
- [Regulatory casework](https://defra.github.io/architecture/patterns/service/regulatory-casework/index.md) (draft): An exploratory starting shape for assessing applications, inspecting, investigating and taking enforcement action - the heart of how Defra regulates.
- [Transactional digital service](https://defra.github.io/architecture/patterns/service/transactional-service/index.md) (draft): An exploratory starting shape for a public-facing Defra service where users apply, register, notify or claim something.
- [Worked example: apply for a licence](https://defra.github.io/architecture/patterns/worked-example/index.md) (published): A fictional Defra service, followed from context to containers, decisions and threats, to show how the service pattern, patterns and guardrails fit together.
- [Sample ADRs](https://defra.github.io/architecture/patterns/worked-example/adrs/index.md) (published): Three architecture decision records from the fictional apply for a licence service, written with the ADR template. Use them as examples of the level of detail we expect.
- [Threat model excerpt](https://defra.github.io/architecture/patterns/worked-example/threat-model/index.md) (published): Part of the alpha threat model for the fictional apply for a licence service, written with the threat model template and the STRIDE method.