Part 1 · Post 3

Three boundaries: facility, country, region

Where data is allowed to live, what may cross each line, and why a storm at 2 a.m. shouldn't matter.

15 November 2026 · 6 min read

The wind brings a branch down across the street, and the facility’s internet goes with it.

In room 14, Mrs Wu sits up and swings her legs out of bed. The bed sensor notices. Twenty metres away, a small box in the comms cupboard decides this is worth an alert, and Priya’s handset buzzes.

She’s there before Mrs Wu has found her slippers. Nobody in the building knows the internet is down, and that’s the point.

Why boundaries come first

Most architecture diagrams start with services. This one starts with lines on a map, because the non-negotiables are about where things happen:

• Identifiable health data stays in Australia.
• Only de-identified metrics go regional.
• Night alerting runs on site and works offline.

Get the lines right and many later decisions follow from them. Get them wrong and no amount of security tooling will fix it.

The map

flowchart TB
    subgraph REG["Regional plane · not designed yet"]
        RM[("De-identified<br/>quality metrics")]
    end
    subgraph AU["Country plane · Australia"]
        subgraph AUE["Australia East · as-built sandbox"]
            PLAT["Landing zone, shared platform,<br/>cloud agents, care data,<br/>logs and audit"]
        end
        subgraph AUSE["Australia Southeast · recovery option"]
            DR["Landing-zone infrastructure only"]
        end
        subgraph FAC["Facility edge · target"]
            NWE["Night Watch:<br/>triage, local alerts,<br/>local event store"]
        end
    end
    subgraph TEN["Microsoft tenant services"]
        IDS["Staff and family identity"]
        A365["Agent 365 registry<br/>logging off"]
    end

    NWE -. "pseudonymised events" .-> PLAT
    PLAT -. "de-identified export only" .-> RM
    PLAT -. "recovery inside Australia" .-> DR
    PLAT --- IDS
    PLAT -. "inventory only, no care content" .-> A365

What’s allowed across each line

This table matters more than the diagram. Each boundary has an explicit allowed list and an explicit never list.

From → to	Allowed	Never
Facility → Australia East	Pseudonymised alert and acknowledgement events, for other agents to use	Raw sensor streams, or anything that alerting depends on
Australia East → regional	De-identified extracts or aggregates, after a review against Australian law	Anything identifiable or re-identifiable about residents, families or staff
Australia East → Agent 365	Agent inventory: names, descriptions, IDs, sponsors	Care content or traces
Australia East → Australia Southeast	Infrastructure recovery within Australia	Any failover outside Australia
Internet → Australia East	HTTPS through Front Door with WAF, to private origins	Direct access to the network; public endpoints on data services

Boundary 1: the facility

Night Watch is the only agent that lives on site. Its triage engine, sensor broker, alert tiers, acknowledgement and escalation, nurse-call adapter and an append-only event log all run in the building.

Two rules make this work:

1. Nothing that alerting needs crosses the line. If the cloud vanished, alerting wouldn’t notice.
2. Only pseudonymised events go up. The cloud uses them to start a draft incident note for an RN, to hold routine family updates, and to inform shift planning. Raw sensor streams stay on site.

Boundary 2: the country

Everything else runs in a single Azure region, Australia East. That covers every resource and every log destination: there’s no cross-region peering, no replication and no log export.

Some less obvious choices also come from this boundary:

• AI models use regional deployments in Australia East, not the global or multi-region “data zone” options, so prompts and responses are processed in-country.
• Family accounts sit in an identity tenant hosted in Australia.
• Network flow logs stay in-region, because network telemetry can include IP metadata about the people using the service.

The line people forget

Some Microsoft services live at the tenant level rather than in a region. Agent 365, which provides a registry and governance for agents, stores its activity data in the tenant’s geography rather than in Australia East.

The design therefore registers each agent’s existence (name, ID, sponsor) and keeps Agent 365 activity logging switched off until a privacy review approves it. That’s an uncomfortable trade-off: it gives up useful telemetry to stay on the right side of the line.

Boundary 3: the region

The brief wants a group-wide view of quality across countries. The only thing allowed to feed it is de-identified data, exported from each country’s record after a de-identification step that is reviewed against Australian law.

This plane is Target, and not designed yet. No regional hub and no cross-border connection exist, and that’s deliberate. Adding one will be a separate, explicit decision.

When Australia East has a bad day

This is where the boundaries get expensive. The obvious recovery site is Australia Southeast, but:

• The FHIR service used for the care record isn’t offered in Australia Southeast (checked 9 Nov 2026).
• The Care Record design also lists Speech, Azure OpenAI and Agent Service as not available there. I need to re-check this before writing the disaster-recovery decision.

Like-for-like failover inside Australia isn’t possible today, and failover outside Australia is never allowed. The working approach is to fail closed and degrade manually:

• The operator’s clinical system stays the system of record, so the FHIR copy can be rebuilt from it.
• Cloud agents pause, or tell people that staff will follow up.
• Caregivers keep documenting in the clinical system directly.
• Night Watch carries on, because it never depended on the cloud.

Honest gaps

That’s Part 1. Next, in Part 2, we go down a layer: an AI landing zone, three kinds of identity, and why “private by default” is harder than it sounds.