How data gets in, who can change it, and what keeps it intact.

One instance and one database per customer. Isolation is a deployment boundary.

• Each customer runs on their own database under their own licence.
• Hosted in the jurisdiction you choose. Records stay in that country. Deployment to a Canadian-owned provider in Canadian data centres is available.
• Self-hosted deployment on your own infrastructure is available.
• Municipal and provincial privacy regimes turn on where records sit and who can reach them: MFIPPA and FIPPA in Ontario, FOIPPA in British Columbia, Alberta's Protection of Privacy Act. Privacy impact assessments are completed in writing.
• The data is yours. Records export in an agreed format on request or at the end of the term and are used for nothing but running your instance.
• Deletion is a soft delete with a retention window, and destruction terms are set in the agreement.

• One instance per customer
• Data residency you choose
• Self-hosted option
• MFIPPA and FIPPA
• Data export on request

Access control enforced at the query layer.

• Rights are granted per record type and per operation. The server refuses the query.
• Record-level restrictions sit on top of role rights.
• SAML 2.0 and OIDC single sign-on, including Microsoft Entra ID. Your identity provider's sign-on URL and signing certificate are pasted into the instance configuration and applied on restart. A claim-mapping layer sits above them.
• Identity-provider groups map to Aptli roles. Unconfigured it is a no-op, and mapping grants only the rights the role already carries.
• Staff accounts use an authenticator app or SMS. One-time recovery codes are issued at enrolment and stored hashed.
• External submitters use a password plus an emailed one-time code, independent of internal single sign-on.
• TLS in transit. Stored integration credentials are encrypted at rest with AES-256-GCM.

• Rights at the query layer
• Record-level restrictions
• SAML 2.0
• OIDC
• Entra ID
• Authenticator app
• Recovery codes
• AES-256-GCM

What it takes to change a record, and what it leaves behind.

• Changes land in a named version. Compare any two side by side and discard one.
• Restoring a committed version stages its previous state as a new draft that passes the same review.
• Undo and redo run across a whole map-editing session before anything is committed.
• Field edits and public submissions arrive for review before they land in the record. A reviewer approves, rejects or returns them with comments, and a completed report carries its own pass, fail or needs-revision verdict.
• The audit log is append-only and exports to CSV, JSON and XLSX. It records what was done, by whom and when.
• Create, edit and delete rights are set per record type and per operation. Responsibility for an asset class sits with a named role.

• Named versions
• Undo and redo
• Approval before it counts
• Append-only audit log
• Per-type rights

The assistant ships switched off, and identifiers are stripped before anything leaves.

• The assistant is disabled on a new instance. An administrator enables it and selects the provider and model.
• Names, emails and phone numbers are replaced with deterministic tokens before a request leaves the instance. The reverse map stays in your own database.
• It proposes and a person applies or discards. It does not commit changes on its own.
• It answers on data explicitly shared with it inside the same role scoping that governs the rest of the system.
• It can point at a self-hosted or regionalized provider. Inference does not have to leave infrastructure you control.

• Ships disabled
• Identifiers pseudonymised
• Proposes, never commits
• Self-hosted option

Recover to any point in time.

• The database runs on MongoDB Atlas point-in-time backup with snapshots taken through the day.
• Retention runs daily, weekly and monthly.
• Restores are tested on a schedule.
• Availability targets are set per contract against the tier the deployment funds.

• Point-in-time backup
• Scheduled snapshots
• Tiered retention
• Verified restores

Severity targets, committed in writing.

• Severity targets and acknowledgement windows are set in the agreement and committed in writing.
• The subscription covers maintenance, support and upgrades.
• In-app bug reporting and help requests reach the same queue as a ticket.
• Self-service documentation is maintained alongside the product.

• Written severity targets
• Maintenance included
• In-app reporting
• Maintained documentation

Releases are checked before they reach you, and a finding stays reproducible afterwards.

• Releases are verified in structured, dated rounds across the platform, the public portal and the content system.
• Each round is append-only: run a check, append a dated row, leave earlier ones alone. A finding stays reproducible months later.
• A written standard the team works to.

• Dated verification rounds
• Append-only records
• Written standard

Built to the AODA standard. Current status and open criteria are available on request.

• An automated axe sweep runs across the prerendered pages in each language, and a static contrast auditor checks foreground and background pairs.
• AODA under O. Reg. 191/11 sets the standard at WCAG 2.0 Level AA. The platform is built and audited to WCAG 2.2 Level AA.
• Current status is partial conformance. Open criteria are tracked with what each affects and where it stands, and the audit output is available on request. A signed compliance statement is answered the same way.

• AODA
• WCAG 2.2 Level AA
• Automated sweeps

The standards the build is held to.

• WCAG 2.2 Level AA under AODA across the platform, the public portal and the content system.
• Data residency enforced by where the instance runs. Canadian residency for Canadian deployments.

• WCAG 2.2 Level AA
• Data sovereignty