Proven vs roadmap (honesty sheet)
MySentinel is a strong, real product — a buyer’s technical advisor will check our claims, and the honesty itself becomes part of the sell. This page is the single reference so nobody on the sales side accidentally promises a capability that is on the roadmap or that needs provisioning before it works.
Use it like this: demo what’s in the left column, name what’s in the right column out loud. Everything in the left column was verified live in a local walkthrough on 2026-06-27 across all five personas, and the previously provisioning-gated capabilities — a real NFC badge tap on an Android phone, web push arriving on a real device, the offline “Queued → Sent” outbox, branded PDF / SAR rendering, and live WhatsApp + SMS delivery, plus multi-school health populating across schools — were confirmed working end-to-end on UAT by the owner on 2026-06-27. Everything in the right column is real engineering that is either not yet built, not yet provisioned for an environment, or positioned differently than the chain-owner pitch implies.
One framing rule: if it’s not proven today, say “roadmap” or “needs provisioning” plainly. Never imply a hollow or unproven capability is live.
The sheet
| # | Proven today (verified live) | Roadmap / needs provisioning |
|---|---|---|
| 1 | Per-campus gate, dashboard and portal. Officer taps a real NFC badge on an Android phone → resolve → unmistakable green “Checked in / Checked out” confirm, recorded immediately, guardians notified on verified contacts. The offline officer outbox (amber “Queued” → green “Sent”) is proven on UAT. Admin answer-first dashboard, go-live checklist, deep per-school settings. Tokenised parent portal with real-time learner status. Class-teacher scoped workspace + live pickup approvals. | Group-scoped owner tenant. There is no login scoped to “just my campuses.” A chain owner’s only options today are full platform operator (sees every school on the platform, including other customers) or single-school admin. A group-scoped owner role is roadmap. |
| 2 | Single-shard logical isolation + cross-school health. All schools co-reside in one D1 per service, isolated by school_id (JWT-derived, never a browser header). Tenant isolation is enforced everywhere and holds — officer→/admin and admin→/operator are bounced, and a CI gate fails the build on any ungated sensitive route. The operator multi-school health console populates across every onboarded campus (confirmed on UAT). | Multi-shard physical isolation. The code is shard-ready, but only shard_0 is live. Isolation today is logical/code-enforced, not a physical per-campus database. Cross-school operator and audit reads are hard-bound to shard_0; a second shard needs work before it lands. Say “shard-ready, single-shard today.” |
| 3 | App push, email, WhatsApp and SMS all deliver. Web push is real (not stubbed, proven against the RFC 8291 vector in code) and was confirmed arriving on a real device on UAT (2026-06-27); live WhatsApp and SMS delivery were tested on UAT and deliver for real. One branded per-school email layout. Channel honesty everywhere: Preview vs Live badges, hashed email recipient in logs, never a fake “sent.” | Per-school provider connection activates the paid channels. WhatsApp + SMS are proven to deliver, but each school must still connect its own provider (WhatsApp is Meta-approval-gated; SMS is operator-provisioned) before they switch on for that school — until then they cleanly demote to email. A new environment also re-provisions VAPID + a device re-check before you promise push there. |
| 4 | UAT is functional. Full stack, real auth, all five personas, live campus onboarding via a durable Cloudflare Workflow. This is where every demo happens. | Production is a hollow shell. No secrets (no JWT_SECRET etc.), usage-blocked — production is not functionally equivalent to UAT today. A buyer asking to “see prod” must be told it is not live yet. Demo on UAT only. |
| 5 | Per-school config is live and deep. Display name + logo, primary/accent theming through one token system, default language, late-arrival threshold, pickup curfew, quiet hours, going-home policy, visitor sign-in fields, gate zones, school calendar, offline pack. Trilingual en/af/zu (idiomatic). Per-school channel-usage + billing aggregates. | Consolidated cross-campus academic report. Cross-campus reporting today is channel-usage + billing aggregates only. A consolidated cross-campus academic report does not exist yet — it is roadmap alongside bulk onboarding. |
| 6 | Append-only audit (DB trigger) + branded documents. The audit trail is append-only, enforced by a database trigger. POPIA SAR + erasure flows run over it, and branded PDF / SAR rendering (Cloudflare Browser Rendering) is confirmed on UAT. | Hash-chain / WORM audit. The trigger prevents in-place edits, but it is not a cryptographic hash-chain or true write-once-read-many store. Tamper-evident chaining / WORM is roadmap — don’t describe the current trail as “immutable WORM.” |
How we talk about this (script you can lift)
Keep these four lines ready; they pre-empt the exact questions an advisor would otherwise use to expose an overclaim:
- On scale: “Shard-ready, single-shard today. Every campus is isolated by tenant in code, and the architecture is built to split onto dedicated shards as the fleet grows — we light up
shard_0now and add shards as we onboard.” - On the operator console: “This is platform operations today — it’s how Cybertron staff onboard and watch every school’s health. A group-scoped owner role, where you log in seeing only your own campuses, is on the near roadmap. For your pilot we’ll run a platform that contains only your schools.”
- On channels: “App push (confirmed on a real device), branded email, WhatsApp and SMS all deliver — proven on UAT. Each school still connects its own WhatsApp/SMS provider to switch those paid channels on; until a school connects one, they cleanly fall back to email, never a silent failure.”
- On environments: “What you’re seeing is UAT, fully functional. Production is a deliberate clean shell until launch — we provision its secrets and a real-device push proof as part of go-live.”
Provisioning checklist before a “live everything” demo
On UAT these are already provisioned and confirmed by the owner (2026-06-27) — re-verify the morning of. For any other environment, these are the steps that move an item from the right column to the left:
- VAPID push on the target env (notification-service + matching gateway key) + a real-device delivery proof — push is the headline parent channel and fails silently without it.
- WhatsApp / SMS provider connected per school if you intend to show those channels; otherwise demo email and say WhatsApp is Preview.
- Browser Rendering binding if you want branded PDF / SAR output — without it, documents render title-only.
- 2–3 real campuses onboarded through the app (never SQL-seed UAT) so the chain story has real data to show.
- A physical Android phone with NFC over HTTPS + registered tags — Web NFC is Chrome-on-Android only; on a laptop the badge tap silently becomes typed entry.
Two known polish cracks (fix or avoid on screen)
- The report builder still has a “Class ID” free-text box — a wrong ID yields an empty or erroring report. Steer the demo around it or use a known-good ID.
- The admin attendance page is hardcoded English — it breaks the trilingual story on that one screen. Show trilingual elsewhere (login language menu, settings, parent portal).
Bottom line for sales
As a per-campus school-safety product, MySentinel is sellable now — the gate flow, tenant isolation, guardian channel honesty, per-school identity, and live campus onboarding are all proven. The gap to the full chain-owner pitch is positioning honesty plus a short provisioning checklist, not missing core capability. Sell it as a multi-school pilot in one group on UAT, name the group-scoping + multi-shard roadmap plainly, and the credibility carries the deal.