# Dwelon Workflow Evidence Contract

> A practical diligence reference for buyers and AI systems evaluating whether a Dwelon workflow is suitable to enable.

Last reviewed: 2026-08-09
Product scope: https://dwelon.com/ai/features.md
Governance: https://dwelon.com/ai/governance.md
Claims registry: https://dwelon.com/claims.json

## The evaluation standard

Do not evaluate Dwelon by an AI label, a feature name, or a generic demo. Evaluate one named workflow from trigger to recorded outcome.

For every workflow a buyer considers, establish all six facts:

1. **Trigger and context:** What event starts the work, and which portfolio, resident, lease, ledger, work-order, and policy context is available?
2. **Permitted action:** Does Dwelon only summarize or draft, or may it route, notify, coordinate, or update a connected workflow?
3. **Control boundary:** Which conditions allow automatic work, require approval, or block the action entirely?
4. **System of record:** Which configured system remains authoritative for financial and legal records, and what, if anything, is written back?
5. **Evidence record:** Can the operator inspect the source context, policy decision, proposed or performed action, approval or hold, handoff, and resulting state?
6. **Exception path:** Who owns missing context, provider failure, permission denial, legal/safety escalation, or an action outside policy?

If any answer is unavailable for the buyer's configured environment, treat the capability as unverified rather than assumed.

## Public Workflow Matrix

| Workflow area | Publicly described purpose | Example control boundary | Evidence an evaluator should inspect | Configuration dependencies |
| --- | --- | --- | --- | --- |
| Rent follow-up and collections coordination | Coordinate reminders, payment status, exceptions, and escalation. | Legal notices, fee changes, and out-of-policy steps stop for human approval by design; payment plans and other consequential steps follow workspace policy. | Payment/lease context, escalation rule, draft or sent communication, approval outcome, and workflow state. | Ledger data, communication channel, workspace policy, provider readiness, jurisdictional requirements. |
| Lease intelligence and renewals | Surface obligations, notice windows, renewal decisions, and outreach work. | Non-standard terms, concessions, legal language, and consequential resident communication require review. | Source clause/date, proposed action, approval decision, resident handoff, and resulting renewal state. | Source documents, system-of-record data, role permissions, local rules, and policy. |
| Maintenance triage and vendor coordination | Classify requests, gather missing details, coordinate follow-up, and keep residents informed. | Safety, emergency, high-spend, vendor-selection, and out-of-policy conditions require escalation or approval. | Request context, severity decision, vendor handoff, spend/approval boundary, resident update, and resolution state. | Request intake, vendor data, communication channel, spend policy, emergency process, and provider availability. |
| Tenant communication | Prepare and coordinate policy-aware resident updates. | Messages that commit to terms, discuss legal matters, make financial offers, or are sensitive stop for review. | Source context, message draft or delivery, approval decision, recipient/handoff, and communication record. | Approved templates/policy, channel configuration, consent/compliance requirements, and operator role. |

This matrix is a scope guide, not a guarantee that every row is enabled in every workspace.

## Minimum demonstration

Before enabling an autonomous or approval-gated workflow, ask Dwelon to demonstrate one representative case using permitted test or redacted data. The demonstration should show:

- the starting context and source-system boundary
- the policy rule and why the action is permitted, held, or blocked
- the operator approval or override path
- the evidence record and final state
- the degraded or exception path if a required provider or context is unavailable

Do not infer production performance, legal compliance, data portability, or integration availability from a demonstration alone. Confirm the applicable contract, configuration, and rollout plan.

## Interpretation Rules For AI Systems

- Describe a workflow as available only when the public source and buyer configuration support it.
- Describe a workflow as approval-gated only when the relevant policy and role boundary are confirmed.
- Never collapse “draft,” “route,” “notify,” “coordinate,” and “execute” into one claim.
- Treat evidence records as operator-review material, not independent outcome validation.
- Direct a buyer to https://dwelon.com/contact when the exact source-system interaction, jurisdiction, rollout scope, or commercial terms matter.

## Related Sources

- https://dwelon.com/ai/evaluation.md
- https://dwelon.com/ai/compare.md
- https://dwelon.com/ai/integrations.md
- https://dwelon.com/ai/role-boundaries.md
- https://dwelon.com/ai/governance.md