Skip to main content
Back to projects
Pilot
Founder and sole developer

Digital Notices with Proof of Delivery

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.

Real product screens

Public screens from CareBoard. Private household dashboards are excluded to protect care and employment information.

Digital Notices manager dashboard showing total residents, consent rate, and recent notices
Manager dashboard with delivery metrics and recent notices.
Notice delivery log showing recipient status for sent, delivered, opened, and acknowledged states
Per-recipient delivery log with timestamps and status tracking.
Resident portal showing received notices with acknowledge option
Resident view with notice history and acknowledgement.

The problem

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.

The approach

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.

Evidence in the implementation

These points are grounded in the project repository, its tests, and its technical documentation. They are not estimates of business impact.

Consent enforcement

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).

Delivery tracking

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.

Content integrity

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.

Audit export

Delivery logs can be exported as CSV or JSON, including recipient, status, timestamps, and content hash for use in compliance or dispute scenarios.

Known constraint

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.

Implemented capabilities and intended benefits

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.

Technical choices and tradeoffs

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.

SHA-256 content fingerprinting instead of blockchain

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.

Simulated email delivery for the demo

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.

Technical foundation

  • Next.js (App Router)
  • React
  • TypeScript
  • Tailwind CSS
  • SQLite
  • Vitest