Skip to content

Method and governance

Proof and method.

The method every build follows, the chassis it runs on, the reference build you can walk through, and where this way of working has already run.

The method

ArkOS: Discover, Design, Build, Deploy.

A published, spec-driven method. Every stage produces a written artefact you can read: briefs, build-specs, decision records, ship records.

The ArkOS methodFour stages in sequence: Discover, then Design, then Build, then Deploy.01Discover02Design03Build04Deploy
  1. 01

    Discover

    Where the load actually sits: the workflows, the systems of record, the people. An idea that does not make a person more capable is parked, in writing.

  2. 02

    Design

    A build-spec with scope, constraints, architecture decisions, data model and an out-of-scope list. Agentic builds carry a governance sheet before any code: each agent's role, authority, bounds and hand-back conditions.

  3. 03

    Build

    Fixed scope, tasks sized in days, decision records for every significant choice. You can read exactly what was decided and why.

  4. 04

    Deploy

    Into your tenant with checklists as state: environment, secrets, rollback. A ship record notes what went live and what it costs to run.

The chassis

Your subscription. Your identity. Your data.

What every build stands on, and what happens to your data: it stays yours, in your tenant, in Australia East.

The ARK360 delivery chassis and what each component means for the buyer
ComponentWhat it means for you
Azure subscriptionYou own the subscription and the data. ARK360 builds inside it and can be removed from it.
Entra IDIdentity and access are your directory, your policies, your joiners and leavers.
Data residencyData resident in Australia East. Nothing routes through third-party services outside your tenancy.
Copilot StudioThe entry tier for governed assistants inside Microsoft 365, where your teams already work.
Claude Agent SDK via Azure AI FoundryDeeper agentic builds authenticate through Azure AI Foundry, so billing and governance stay in your tenant.
Reusable MCP integrationsConnections to your systems of record are built once as governed integrations and reused across builds.
Outbound actionsNothing outbound is ever autonomous. Drafts are prepared for a person; a person sends.
Your tenant is the boundaryA single boundary drawn around your Azure subscription. Inside it: Entra ID identity, data resident in Australia East, Copilot Studio as the entry tier, and agents authenticated through Azure AI Foundry so billing and governance stay yours. Nothing outbound is autonomous.YOUR AZURE SUBSCRIPTIONEntra IDyour identityData · Australia Eastyour residencyCopilot Studioentry tierAgents via AI Foundryyour billing, your governanceNothing outbound is ever autonomous. Drafts are prepared for a person; a person sends.

Governance

Why it keeps working after the demo.

None of this is compliance theatre. It is the reason the build still behaves in month six: measured, bounded, auditable, and priced to run.

Evaluations

Every build ships with evaluations that run before and after changes, so behaviour is measured, not assumed.

Human in the loop

Workflows are designed around the person: the system prepares, the person decides. Hand-back conditions are written down before a build starts.

Audit trails

Every agent action lands in an audit record: what acted, under which authority, with what outcome and cost.

Delegated, bounded authority

Each agent holds the narrowest authority that does the job, recorded in a governance sheet you can read.

Cost envelopes

Token and compute spend is capped and visible per workflow, so the running cost is a number, not a surprise.

The governance loopThe person delegates bounded authority to the system. The system prepares and acts within those bounds. Every action returns through the audit trail and evaluations to the person, who stays in command.The personalways in commandThe systemprepares and acts in boundsDELEGATED, BOUNDED AUTHORITYAUDIT TRAIL · EVALUATIONS · HAND-BACKCOST ENVELOPE

What it is

Not a product. A demonstration.

It has no paying customers and no live operators. It is a reference build and an integration substrate, not a product I am selling you. It exists so you can see the method working before you commission anything.

That status is stated plainly because the value of this page depends on it. Anyone can show you a demo. A complete platform, built under the same method offered to you, is something you can interrogate: how it is structured, how authority is bounded, what it costs to run.

The walkthrough

Five parts, one platform.

Each part exists because a build-to-rent operator needs it on day one. Together they cover the operational surface end to end.

Access control core

The permission and credential engine: who can open which door, when, under whose authority, and the auditable event stream every decision leaves behind.

Resident app

A .NET MAUI app for residents: access, requests and communications in one place, against the same core the operator sees.

Operator console

A Blazor console for the operating team: occupancy, access events, requests and the day's work in one view.

Biometric hardware integration

Physical access hardware treated as a governed boundary: hardware events flow in, permission decisions flow out, and both are logged.

Admin and reporting

Estate configuration, roles and the reporting an operator answers for, drawn from the same records the workflows write.

Built on .NET Aspire, ASP.NET Core, Blazor and .NET MAUI, with MCP integrations.

Why it matters to you

An integration substrate, not a sales pitch.

The useful part for a buyer is not the platform itself. It is what sits underneath: governed integration patterns for identity, access events, resident communications and reporting, built once and reusable. Client builds draw on that substrate instead of starting from a blank page.

If you commission a build, you are not buying BTR OS. You are engaging the method that produced it, applied to your workflows, your systems of record and your tenant.

Read the method behind it

Delivery record

Four engagements, described by category.

Federal government

A Power Platform Centre of Excellence

Delivered as employed work, not ARK360 client work.

Stood up the governance, pipelines and maker enablement for a federal agency's Power Platform estate: environment strategy, DLP policy, application lifecycle and support model.

What persisted: The CoE operating model and governance remained in daily use after handover.

Civil construction

Agentic AI in a tier-one civil business

Delivered as contract work, not ARK360 client work.

Designed and delivered agentic AI workflows for engineering and commercial teams on the Microsoft platform, including a technical health review agent that produced its first working proof of concept in one week and moved into a production build.

What persisted: The governed-agent pattern and the delivery method carried into subsequent internal builds.

High assurance

An Azure OpenAI pattern for a regulated environment

Delivered as contract work, not ARK360 client work.

Designed an Azure OpenAI integration pattern for a high-assurance environment: private networking, identity-bound access, prompt and output logging, and data-residency controls in the customer tenant.

What persisted: The pattern was adopted as the reference for later AI workloads in that environment.

Property and development

Enterprise delivery across property and development

Delivered as employed and contract work, not ARK360 client work.

Seventeen-plus years across property, development and construction businesses on the Microsoft platform: from SharePoint and .NET estates through Power Platform to AI-era workloads, always inside the owner's tenant.

What persisted: Platforms and operating patterns that teams still run.

Names are withheld deliberately. Employers and clients are described by category, and outcomes are limited to what I can state plainly and stand behind. Specifics can be discussed in conversation where confidentiality allows.