This is the final evidence gate before account beta or public production. A checkbox without evidence does not pass. Complete the record in:

Settings -> Global Settings -> Governance and Deployment Gate

Run:

pnpm governance:check

Local pilot mode reports incomplete items as checks. Account beta and public production report them as release-blocking actions.

1. Trusted HTTPS

Pass only when:

• the live hostname opens without a certificate warning in a normal browser on a separate device.
• the certificate hostname matches, has a trusted issuer, and is not expired.
• all HTTP requests redirect to HTTPS.
• secure cookies are enabled.
• BAND_LICENCE_TRUSTED_HTTPS=true is set only after the test.
• the certificate issuer, expiry date, hostname, device, browser, date, and tester are recorded.

The self-signed local camera-scanning certificate does not pass this gate.

Use deploy/caddy/Caddyfile.teacher-app.example as the trusted reverse-proxy starting point. Then run pnpm monitor:check against the live address. Node rejects an untrusted certificate.

2. Durable Abuse Protection

The app now stores request-rate windows and blocked security events in SQLite, so protection survives an application restart. It covers:

• public QR profile session exchange.
• broad sign-in attempts from one client.
• repeated sign-in attempts for one client and account.
• the existing persistent per-account failed-sign-in lockout.

Before account beta:

• set BAND_LICENCE_RATE_LIMIT_SECRET to a long random value outside source control.
• in Global Settings, select Run Safe Protection Test. This uses a synthetic identifier, confirms that the first two requests are allowed, the excess request is blocked, the request bucket is stored, and a privacy-safe security event is recorded. It never tries a real account password.
• restart the app, return to Global Settings, and run the safe test again. The recorded evidence should then say that a self-test event from the earlier process survived the restart.
• create a dedicated temporary test account with no access to live student data. Make five failed sign-in attempts, confirm the account is locked for 15 minutes, then have an Administrator use the existing unlock control. Never run this test against the only owner Administrator account.
• record the date, test route, expected threshold, observed result, and tester.
• add the dedicated test-account lockout result and the responsible person's name to the evidence, then select the confirmation checkbox and save. The automated test intentionally does not select this checkbox for you.
• keep the teacher app behind a firewall/reverse proxy; application throttling is not a replacement for network protection.

3. Monitoring and Alerts

The non-sensitive /api/health endpoint reports database readability, exact schema state, verified-backup state, deployment mode, secure-cookie state, and aggregate security-event counts. Deep database integrity is verified out of band by backup, migration, restore, and deployment checks. The endpoint does not return student, account, address, or token details.

Run:

BAND_LICENCE_MONITOR_URL=https://app.example.com pnpm monitor:check

The check writes capped history to data/monitoring/health-checks.ndjson. A failure also creates data/monitoring/current-alert.json and exits unsuccessfully.

For a genuine outage alert:

• schedule the command from a separate trusted device, not only the app host.
• run it at an agreed interval.
• make the scheduler alert the responsible person when the command fails.
• deliberately stop the app once and confirm the alert arrives.
• record the monitoring device, interval, destination, drill date, and outcome.

4. School, Privacy, and Child-safety Approval

The app cannot approve itself. Record:

• approving school and person.
• the approver's role.
• approval date.
• privacy and child-safety document versions reviewed.
• approved uses, devices, users, data, QR access, Lesson Notes, and conditions.
• correction, deletion, retention, support, and escalation contacts.

Private schools are usually covered by the Australian Privacy Act in circumstances described by the OAIC. Confirm the exact position with each school and its advisers:

• OAIC: Children and young people
• OAIC: Guide to securing personal information
• National Principles for Child Safe Organisations

5. Incident Response

Open /docs/INCIDENT_RESPONSE_PLAN.md, assign the named responsibilities, and run a tabletop rehearsal. Record the scenario, participants, date, decisions, timing, gaps, and completed follow-up work.

The OAIC recommends a written, regularly tested response plan:

• OAIC: Preparing a data breach response plan
• Cyber.gov.au: Guidelines for cyber security documentation

6. Physical Device and Printer Testing

Open /docs/PHYSICAL_DEVICE_PRINTER_TEST.md and test the real equipment that will be used:

• host computer and restart.
• desktop and tablet browsers.
• USB and Bluetooth scanners.
• phone/tablet camera scanning where approved.
• card printing at 85 mm x 54 mm with approximately 20 mm QR code.
• timetable, report, card, PDF, portrait, and landscape output.
• printer scaling at 100 percent with measured paper output.

Record each device, operating system, browser, scanner/printer model, result, measurement, date, and tester. Screenshots alone do not prove physical print size.

Release Decision

Only mark the gate 6/6 evidenced when every item above has a named owner and verifiable evidence. An unresolved condition remains visible in Gate Notes and blocks wider release.