SQLite for single-deployment simplicity
Why: A self-contained database keeps the demo simple and portable without external dependencies.
Tradeoff: Single-node storage; scaling would require migration to a networked database.
A demo app for BC property and strata managers that sends formal notices digitally, tracks resident consent, records delivery status, and produces audit-ready proof-of-delivery logs.
This is a demo application. Emails are simulated and delivery does not constitute legal service. Confirm service rules with the RTB or a lawyer.
Public screens from CareBoard. Private household dashboards are excluded to protect care and employment information.
Property and strata managers in BC need documented proof that residents received formal notices. Paper notices lack delivery confirmation, and digital delivery requires recorded consent. Without a clear audit trail, managers cannot demonstrate compliance when disputes arise.
A notice-delivery system that records resident consent (date and method, such as the RTB-51 form), blocks delivery to residents who have not consented, tracks each notice through sent, delivered, opened, and acknowledged states, and produces timestamped proof-of-delivery logs with SHA-256 content fingerprints.
These points are grounded in the project repository, its tests, and its technical documentation. They are not estimates of business impact.
The system blocks digital delivery to residents who have not provided consent. Consent records include date and method (such as an RTB-51 form reference).
Each recipient's delivery status is tracked independently: sent (email dispatched), delivered (received by mail server), opened (email opened), and acknowledged (resident confirmed receipt). Timestamps are recorded for each state.
A SHA-256 hash of the notice content is computed and stored when the notice is created, providing proof that the content has not been modified after delivery.
Delivery logs can be exported as CSV or JSON, including recipient, status, timestamps, and content hash for use in compliance or dispute scenarios.
This is a demo application. Emails are simulated and not actually sent. The system does not constitute legal service of notices. Confirm service rules with the Residential Tenancy Branch or a lawyer.
Delivery tracking and consent recording are demonstrated in the app. Legal compliance and real-world effectiveness have not been verified.
Resident consent recording with date, method (e.g. RTB-51), and opt-out handling
Evidence: Demonstrated in the resident management interface.
Per-recipient delivery tracking: sent, delivered, opened, acknowledged
Evidence: Visible in the notice delivery log with timestamps.
SHA-256 content fingerprint for each notice, proving the content has not changed
Evidence: Hash displayed on each notice detail page.
CSV and JSON audit export for proof-of-delivery logs
Evidence: Export button available on the notice detail page.
Resident portal for viewing and acknowledging notices
Evidence: Demonstrated in the resident-facing interface.
Designed to provide an audit trail for regulatory or dispute scenarios
Design intent; measured impact has not been established.
Why: A self-contained database keeps the demo simple and portable without external dependencies.
Tradeoff: Single-node storage; scaling would require migration to a networked database.
Why: A cryptographic hash provides tamper evidence without the complexity or cost of blockchain infrastructure.
Tradeoff: The hash proves content integrity but does not provide third-party timestamping.
Why: Avoids sending real emails during demonstrations while showing the full delivery workflow.
Tradeoff: Actual email deliverability, bounce handling, and spam filtering are not tested.