Trust
Trust
Aptoria Trust Spine System Card: Boundaries, Intercepts, and Action Records
Aptoria is AI property management software for landlords and small-to-mid-size property-management firms. This plain-language system card covers the actions Aptoria prohibits or requires humans to review, the cancellation window planned for money movements, and the records Aptoria keeps.
Updated October 2026
Human oversight
Humans stay in control.
Agents stay in bounds.
Who can approve what, when the agent can act, and how exceptions escalate.
Review who can approve what
Audit trail
Every decision has a record.
What happened, why, which policy applied, and who approved it — the chain of context Aptoria keeps for supported actions.
Trace a decision in the demo
Property-management software can affect money, housing, vendors, and tenant communications. A security page alone does not explain who remains responsible for those outcomes. This public system card describes Aptoria’s current product boundaries so a customer can compare the copy with the configured workflow, provider state, and resulting activity record.
1. Prohibitions and Human Review
Aptoria has 14 hardcoded limits no setting can switch off: 8 actions always require a human, and 6 are prohibited outright. Aptoria’s current execution controls keep those published consequential action classes on a restricted floor. Customers are not offered a setting that enables autonomous execution for these classes. The authorized person makes the decision and runs any required external process.
The current public action classes are generated from the same reviewed product-control registry used by Aptoria’s other trust surfaces:
Approval cannot enable prohibited actions. Human review does not activate a workflow. This boundary is not a legal conclusion or compliance certification.
The floor is an execution boundary for supported Aptoria workflows. It does not monitor activity completed outside Aptoria, establish that a customer’s process is lawful, or remove the customer’s responsibility for the decision.
2. The Soft-Commit Workflow
When rent payments are enabled, eligible pending money movements will have a 15-minute cancellation window; no money moves through Aptoria today. Aptoria doesn’t carry out routine work on its own yet. Today you can set the limits it will work within, and its hardcoded limits are published. The window is part of the planned payment workflow: an eligible pending action will wait 15 minutes before it runs, and cancelling it in that time will stop it.
What the window will and will not do
When rent payments are enabled, the window will apply to eligible pending actions only. It will not be a universal hold on payments, messages, vendor work, or provider operations.
It will not reverse a provider or external action that has already completed; corrections, refunds, disputes, and other remedies will follow the provider’s process.
Undo for autonomous actions is planned; nothing runs on its own today. The emergency stop pauses Aptoria for your whole organization and cancels anything still pending; because nothing runs on its own today, there is nothing for it to stop yet.
3. Reviewable Action History
Nothing runs on its own in Aptoria today, so there are no agent actions to record yet. When agent actions are enabled, each will be recorded with its policy, approval, and outcome context, and some records will carry hash-chain context that can help reveal a later mismatch. Coverage will depend on the record type and workflow; an activity entry will not be proof that an external provider delivered, settled, filed, or accepted an action.
Action history is an operational review artifact, not a complete legal record. It does not prove admissibility or promise acceptance by a court, regulator, auditor, insurer, tenant, or provider. Customers remain responsible for their own retention duties and for preserving source and provider records appropriate to the matter.
When record export is enabled, review its scope and verification details before relying on it.
4. Product Control Specification
A product label such as “AI agent” does not describe what the software may do. The useful specification separates assistance from authority, records the controls that can narrow an action, and identifies the evidence needed to verify an external outcome. This table summarizes the current public control model; availability still has to be checked for the specific workflow and account.
This is a product-control record, not a certification of legal compliance, workflow availability, or external outcome.
How to use this specification
For a purchase or implementation review, replace each general row with the exact workflow, property, provider, policy version, responsible person, exception path, and expected receipt. If a field is unsupported or unavailable, stop and resolve it rather than filling the gap with a marketing assumption.
Why These Boundaries Matter
Bounded automation is useful when its authority, stop points, and evidence are visible. The human-required floor prevents selected consequential decision classes from being delegated to Aptoria. When rent payments are enabled, the soft-commit window will give eligible pending money movements a 15-minute cancellation opportunity. Action history makes the product’s own workflow easier to inspect. Each control has a defined scope, and none transfers legal or operational responsibility away from the customer.
That scope is part of the product design: availability can depend on the property, jurisdiction, provider, account, plan, configured policy, and current release. The Trust Center and Availability pages publish the current status and launch requirements for customer-facing workflows.
How to Evaluate the Controls
Key takeaways
Aptoria publishes a human-required floor for defined consequential action classes in supported workflows.
The 15-minute soft-commit cancellation window is planned for eligible pending money movements; no money moves through Aptoria today.
Action history is an operational record, not a legal or compliance certification.
Evaluate AI software with a field-by-field control specification instead of inferring authority from an “agent” or “automation” label.
Evaluate each workflow against its current configuration, provider state, limits, and responsible human owner before relying on it.