The boundary comes first.

Email is live in Sydney today. Everything after it earns its place only when we can explain where the relevant data goes, how long it stays, and what the customer can inspect.

These are directions, not products you can buy or rely on today.

Three workloads. The same standard.

The roadmap is intentionally short. New capability should reduce the work needed to answer a residency question, not create a new system a customer has to audit.

  1. 01Directional

    Connect more of the stack.

    Boundry Automations already provides the regional workflow model. The roadmap is a broader catalog of signed, reviewed apps without weakening the runtime boundary.

    Automation apps
    Boundry workflow editor showing an inbound email trigger connected to a Slack channel action.
  2. 02Directional

    Extract documents inside the boundary.

    Upload, temporary storage, extraction, results, and deletion must all be described by the regional manifest. This is the next workload we want to prove with Australian design partners.

    Document extraction
  3. 03Directional

    Apply the model to messages.

    SMS and conversations bring the same question back: where do message content, delivery records, provider events, and operational logs go? The answer needs to be as specific as it is for email.

    Messaging

Start with the email problem you have today.

npm install boundry-sdk
Create a Sydney project