Skip to content
ARK360

The platform

One operating layer, across the systems you already run.

ARK360 is a Build-to-Rent operating platform in five areas: access, residents, leasing, operations and the governed layer an agent acts through. Your property-management, access, finance and messaging systems stay the record.

How it fits

Alongside your systems, never replacing them.

System of record

Your property management system

Unchanged, yours, in place.

  • Reads context
  • Writes back what a person approved

Operating layer

ARK360

Carries the coordination beside it, under authority you set.

No migration, no parallel source of truth, and no argument about which system is right.

Capability map

What is shipped, what is partial, and what is not built.

This is the platform's own capability map, published rather than summarised. The Partial column is the one a marketer would remove, and it is the reason the other two are worth reading. A pilot is scoped against this table, not against a brochure.

Access

Doors, credentials and the event stream, with the access-control platform staying the record.

Shipped

Built, and working in the running build.

  • A multi-site door directory, with access levels, schedules and device groups
  • BioStar Air cloud integration, kept as the access-control system of record
  • A real-time access-event stream into the operator console
  • Digital key and BLE unlock in the resident app through Airfob, validated on physical hardware

Partial

Built underneath, and not reachable end to end yet.

  • Credential revocation on move-out is best effort, and a failure is currently swallowed rather than raised

Roadmap

Not built. Named here so it cannot be implied elsewhere.

  • Named property-management vendor connectors beyond the generic adapter

Resident

The record of who lives where, how they moved in, and who they let through the door.

Shipped

Built, and working in the running build.

  • Resident and unit records
  • A move-in workflow with staged onboarding: unit confirmation, documents, identity verification, lease, payment and key provisioning
  • Visitor invitations and passes
  • Identity verification at a data-minimised third-party provider

Partial

Built underneath, and not reachable end to end yet.

  • SMS delivery is a no-op in production, so phone verification cannot complete

Roadmap

Not built. Named here so it cannot be implied elsewhere.

  • Paying rent from the resident app, which today presents a rent statement that is read only
  • Enhanced move-out and renewal lifecycle automation
  • Bulk resident import

Leasing

Tenancies and the money attached to them, recorded operator-side.

Shipped

Built, and working in the running build.

  • Tenancy records carrying rent amount, cadence and status
  • Unit-to-tenancy linkage
  • Operator-side payment recording, marking paid, refunds and arrears
  • A card-present-never payment model: no cardholder data is stored, only provider references, with exactly-once transition-safe webhooks and atomic refunds

Roadmap

Not built. Named here so it cannot be implied elsewhere.

  • Full leasing-cycle automation, covering renewals and rent reviews
  • An enquiry-to-application funnel
  • An Australian tenancy-law model: bond lodgement, notice periods and statutory receipts

Operations

The coordination work: requests, parcels, announcements and the state of a job.

Shipped

Built, and working in the running build.

  • Parcel logging
  • Service requests with category and status tracking
  • Operator notifications, in-app and push
  • Community announcements
  • Resident feedback

Partial

Built underneath, and not reachable end to end yet.

  • Amenity booking has atomic capacity claims and a filtered unique index underneath it, but no user-facing path calls them, so an operator makes the booking

Roadmap

Not built. Named here so it cannot be implied elsewhere.

  • Resident-initiated booking
  • Vendor and contractor workflow coordination
  • Escalation and service-level tracking

Intelligence

Sentinel: the governed surface an agent acts through, built before the agent.

Shipped

Built, and working in the running build.

  • An MCP Gateway exposing 47 governed tools across 9 categories: doors, users, access levels, visitors, events, schedules, sites, devices and user groups
  • Fail-closed authentication, so an authorisation that cannot be evaluated is refused rather than allowed
  • Role-ceiling enforcement, so a caller cannot exceed the authority of the role it holds
  • A required confirmation before any destructive action

Partial

Built underneath, and not reachable end to end yet.

  • Tool invocations are not written to the audit log, so this layer is role-bounded and confirmation-gated rather than auditable end to end
  • The gateway is not reachable in the current deployment

Roadmap

Not built. Named here so it cannot be implied elsewhere.

  • Agents that call the gateway
  • Multi-agent orchestration across workflows

Questions

What operators ask first.

The answers are on this page already. These are the five that decide whether to keep reading.

What is ARK360?
An AI-native operating platform for Build-to-Rent. It puts governed AI teammates inside the roles an operator already staffs, so leasing, community and operations teams carry less coordination and keep the judgement. It is a complete reference platform, now selecting its first operators, with no paying customers and no live operators.
Does ARK360 replace our property management system?
No. Your property-management, access, finance and messaging systems stay the record. ARK360 reads context from them, prepares the next action, coordinates approved work across them, and writes back the outcomes your team authorises. There is no migration and no parallel source of truth.
What can an agent do without a person approving it?
Nothing that leaves the building, and today nothing at all: the governed surface an agent would act through is built and the agents that call it are roadmap. The surface is 47 tools behind fail-closed authentication, a fixed role ceiling an agent cannot exceed, and a required confirmation before anything destructive. Authority is bounded and confirmation-gated before the first agent connects, which is the order that makes it worth trusting. Messages are drafted for release; nothing reaches a resident, a supplier or a prospect until a person releases it.
Where is our data stored?
In an Australian region, on infrastructure you can point at. Agents authenticate through your directory as principals you can see and revoke, and your systems remain the record.
How does a team start?
With one role, one governed workflow, and the boundaries agreed before anything runs. That is the Founding Pilot Programme, and a pilot starts with a single role rather than a department.
Apply for the Founding Pilot Programme