Property intelligence, made operational.
Leasing, accounting, maintenance, owners, vendors, documents, and assets in one governed operating system — every workflow connected to the same property record, the same financial record, and the same asset history.
Property teams already have leasing, accounting, and maintenance software. What they rarely have is one record those workflows agree on. The seams show up as spreadsheets, re-keyed data, and an audit trail that stops at the module boundary.
Leasing and maintenance exist, but records do not behave like one operational chain.
Accounting is powerful, but physical asset context is thin.
Documents exist, but not as a connected evidence graph.
AI appears as assistance, not as governed action infrastructure.
One canonical property operations model.
Operational and financial events tied to the same property graph.
Assets, vendors, documents, and approvals connected by design.
AI introduced only with policy, auditability, and human control.
Portfolio, property, unit, lease, owner, vendor, and resident tied to one governed record.
Work orders, approvals, invoices, notices, and reports connected to real operational context.
Every financial and operational action reviewable, permissioned, and auditable.
From resident request to owner report, the chain stays intact.
Every figure below comes from flask seed demo — three properties,
26 units, 19 active leases, three months of invoices and payments, and maintenance
running through to completed work orders.
| Order | Title | Trade | Priority | Status | Due |
|---|---|---|---|---|---|
| WO-000004 | Heating not reaching the bedroom | hvac | High | In progress | in 62h |
| WO-000005 | Front door lock sticking | general | High | Assigned | in 68h |
| WO-000002 | Kitchen tap dripping | plumbing | Low | In progress | in 29d |
| WO-000001 | No hot water in the bathroom | plumbing | Emergency | Completed | resolved |
“No hot water” was submitted as normal priority. Atlas reclassified it as a habitability emergency on intake — statutory response clocks are not a triage opinion.
| Code | Account | Debit | Credit |
|---|---|---|---|
| 1000 | Cash — Operating | $157,850.00 | — |
| 1100 | Accounts Receivable | $169,450.00 | $157,850.00 |
| 4000 | Rental Income | — | $169,450.00 |
| Totals | $338,750.00 | $338,750.00 |
The invariant is enforced three times: in the service, by a flush-time
recomputation from the lines, and by a database CHECK.
| Seq | Action | Resource | Hash |
|---|---|---|---|
| 311 | maintenance.work_order_completed | WO-000001 | a3f7c1e0… |
| 310 | ledger.journal_posted | JE-000110 | 7b21d94f… |
| 309 | ar.payment_applied | PMT-000053 | c08e5a2b… |
| 308 | ar.invoice_issued | INV-000057 | 1d6fb730… |
Each event hashes its predecessor. Altering or removing any row breaks every hash after it, and verification reports the exact sequence where it starts.
Service scoping, an ORM guard that refuses unscoped tenant queries, and PostgreSQL
row-level security. Plus a build-failing invariant: a table carrying org_id
without being enrolled fails CI — the mistake that is invisible in review.
Append-only events chained by SHA-256 per organization. Tampering is not prevented — it is made undeniable, which is the property compliance actually asks for.
One policy engine combining role scopes with ownership predicates. An unknown action fails closed. Money movement demands a fresh MFA assertion. The test suite walks the whole role × action × resource matrix.
Decimal end to end, NUMERIC on PostgreSQL and scaled integers
on SQLite — because a float ledger makes 0.10 + 0.20 equal
0.30000000000000004, and a test that lets that pass is worse than no test.
# clone, install, and seed a complete demo organization git clone https://github.com/ibuilder/atlas.git && cd atlas make setup make demo # or bring up Postgres, Redis, web, worker, and beat docker compose up --build
make demo prints a sign-in for every role — administrator, controller,
accountant, property manager, leasing agent, dispatcher, auditor, resident, owner,
and vendor — so every surface is walkable from one seed.
Version 0.5.0 completes every roadmap item through asset intelligence. It is not 1.0: four conditions remain open, and they are the ones code cannot satisfy. The full matrix is in FEATURES.md; a roadmap that reads as a feature list is how a buyer discovers the gap during implementation.
| Area | Status | Notes |
|---|---|---|
| Tenancy, audit, authorization | Complete | Three layers including PostgreSQL row-level security |
| Identity, MFA, SSO, directory provisioning | Complete | OIDC with PKCE, SAML 2.0, SCIM |
| Ledger, AR, AP, reconciliation, close | Complete | Statements, recurring billing, delinquency |
| Maintenance, inspections, preventive work | Complete | Offline inspection replay is idempotent |
| Automation, approvals, webhooks, reporting | Complete | Dry run cannot mutate; conditions are data, not code |
| Documents, assets, capital planning, spaces | Complete | Extraction is a suggestion a person accepts |
| Leasing: applications, screening, renewals | Modelled | Schema and statutory deadlines; no workflow yet |
| Resident, owner, and vendor portals | Partial | Read surfaces complete; some writes API-only |