Access and account protection

• Passwordless links are single-use, retained only as SHA-256 digests and expire after 15 minutes.
• Opening a link with GET or HEAD shows a confirmation page without redeeming the token, creating a session or setting a cookie. Submitting that page redeems the token once; automation that submits forms can still consume it.
• Syntactically valid production sign-in requests use the same browser result for eligible, ineligible and issuance-limited addresses. Suppressed requests create no token and do not call the email provider; this does not remove timing or provider-level side channels.
• Rolling address and service-wide request limits continue to count links after they are used.
• Session cookies are HttpOnly and same-site; active devices show useful last-active times and can be revoked remotely.
• Session creation, revocation, sign-out and scheme-access changes have append-only user-scoped history.
• Accounts can enable authenticator MFA with an encrypted account-bound secret, replay-resistant codes and ten one-time recovery codes stored only as hashes. Enrolled accounts must complete MFA after every email-link sign-in.
• Production platform administrators must enroll authenticator MFA before entering the separate founder boundary and cannot disable it while allowlisted.
• Scheme roles are re-checked at every Server Action and private API boundary; unknown roles fail closed.
• The complete private scheme archive requires recent sensitive authentication; an enrolled account must provide fresh MFA.
• Private exports, source evidence and generated PDFs have per-account hourly ceilings backed by retained activity, without IP-address or device-fingerprint collection.
• Each HTML response receives a fresh cryptographic nonce; production page scripts and styles permit no unsafe inline execution, and scripts permit no dynamic evaluation.

Financial records and evidence

• Money is stored as integer cents and reconciliations must reproduce retained statement balances.
• Issued levy periods and their per-lot fund allocations are retained and database-immutable; corrections use a reasoned void and re-issue.
• SQLite atomically blocks duplicate active supplier invoice numbers, payments beyond the invoice balance and overwriting or deleting original invoice/payment sources.
• Owner receipts are immutable and retained, and active bank matches must be unique and exactly agree with an active same-scheme receipt, supplier payment or other-income entry.
• Manual receipt, expense/payment, other-income, adjustment/reversal and transfer forms retain an operation identity: retrying the same submitted details reuses the original record, while changed details under that identity are rejected. A separately opened form remains a separate operation.
• Levy and arrears email handoffs retain the exact PDF and provider request before the call. Ambiguous calls can reuse only that body and idempotency key inside a 23-hour safety window; older unresolved operations stop for review. Provider acceptance is not evidence of recipient delivery.
• Payments, expenses, documents, bank evidence and other controlled records are voided or reversed instead of silently deleted; live bank dependencies must be removed first.
• Important mutations, downloads and exports are written to a scheme-scoped append-only activity ledger.
• Releasing a closed accounting period requires one financial authority to request it and a different recently confirmed treasurer or chair to approve it.
• Committee invitations, roles and access-status changes require a recently confirmed treasurer or chair session.
• Uploaded evidence keeps its original bytes, declared type, size and SHA-256 integrity fingerprint.
• Each scheme has a 64 MiB technical ceiling shared by retained source files, bank-statement CSVs and generated PDFs. Existing history is never removed to make room; account-wide metadata growth and reviewed offline transfer remain separate operational controls.
• Authorised office bearers can download a versioned, portable scheme archive with a payload manifest and independently fingerprinted source evidence, then verify it locally in the browser. The one-shot JSON route has explicit row, source-byte and final-response limits; larger archives require a reviewed offline transfer.
• Authenticated members can submit private records requests; office bearers release deliberately selected, integrity-manifested ZIP packs to that requester and can later withdraw access without deleting history.
• After recent login confirmation, an office bearer can create a recorded-recipient bearer link for one pack that expires within seven days; the raw token is shown once, immediate revocation and pack withdrawal end access, and successful downloads retain no IP address or device fingerprint.

Verification and recovery

• The release gate runs unit/accounting tests, fresh migrations, deliberate tamper detection, clean lint and a production build.
• An isolated production server exercises authentication, role denial, cross-scheme isolation, exports, evidence and accounting workflows.
• The release bundle is checked for databases, data directories, environment files, private keys and credentials.
• SQLite snapshots have checksum manifests, integrity and foreign-key verification, isolated restore drills and tamper rejection.

Repository snapshot tooling is local and unencrypted. Encrypted automated production backups, off-site isolation, monitoring, retention and full-environment restore drills remain required before paid customer records are accepted.

Current product boundary

• Current scope is NSW self-managed strata schemes with 2–10 lots.
• Financial preparation outputs are working papers; they are not audited, certified or represented as adopted statements.
• Compliance calendar dates must be entered from a source reviewed by the committee or its adviser. StrataTally does not invent them.
• StrataTally records scheme money but does not hold, move or control the owners corporation's bank funds.
• Deployment-provider, subprocessor and data-location statements require a reviewed production configuration and contract register.

Known safeguards still missing

• A reviewed lost-device recovery process, optional passkeys, and mandatory MFA or equivalent controls for any additional high-risk roles found during threat modelling.
• Provider and edge controls for sign-in automation, delivery abuse, timing side channels and form-submitting link scanners.
• Signed email-provider event reconciliation and monitored delivery, bounce and complaint operations.
• Malware scanning for uploaded documents and independently managed production encryption keys.
• A completed privacy impact assessment, vendor register and eligible-data-breach response review.
• Provider-level denial-of-service protection and monitored production security alerts.
• An independent penetration test and reviewed legal/accounting sign-off before broad paid launch.
• Approved production record-retention, legal-hold, disposal and de-identification workflows.