Validator Notes
These notes are written for a deliverable validator on the client side: a person whose job is to confirm that each Phase 1 capability the client asked for has actually been delivered, by reproducing it in the live OneProtect console. You do not need to read code, run scripts, or be a developer.
Each note follows the same shape:
- What the client asked for — the requirement in the client's own words, quoted from the SRS and the architectural response document.
- What this proves — the capability in plain language.
- How it works (at a glance) — a simple block diagram of the moving parts.
- Where to look in the portal — the exact navigation path.
- Validation walkthrough — numbered steps you repeat in the portal, each with the result you should observe.
- Pass / fail checklist — tick each box; if all are ticked, the deliverable is met.
- Intentionally not in Phase 1 — items deliberately deferred, so a deliverable is not failed for a capability that was never in scope.
- Evidence to capture — screenshots or audit entries to attach to your sign-off.
How to use these notes
- Log into the OneProtect console at the URL your team was given, using the role the note asks for (tenant admin, operator, or auditor).
- Open the relevant note and follow the Validation walkthrough top to bottom.
- After each step, confirm the "What you should see" column matches what the portal shows.
- Tick the Pass / fail checklist. Capture the listed evidence.
- If a step does not match, stop and note the step number — that is the precise point of failure to report back.
Requirement → Validator Note traceability
Every Phase 1 capability maps to exactly one validator note below. "Status" describes how complete the capability is for Phase 1.
| Client requirement (SRS / response document) | Note | Status |
|---|---|---|
| Tenant-owned endpoint enrollment over HTTPS | VN-01 Endpoint Enrollment & Asset Visibility | Delivered |
| Managed device / asset visibility | VN-01 Endpoint Enrollment & Asset Visibility | Delivered |
| Browser SSH: recording, command logging, JIT access, RBAC, timeouts | VN-02 Browser SSH Session | Delivered |
| Authorized active/passive discovery scope model | VN-03 Authorized Asset Discovery | Delivered (authorization layer) |
| Compliance policy catalog (SOC 2 / HIPAA / GLBA) + tenant forks | VN-04 Compliance Controls & Policy Forking | Delivered |
| Auditor: time-boxed access, read-action audit, CSV+hash, PDF watermark, redaction | VN-05 Auditor Access & Exports | Delivered |
| SCIM 2.0 provisioning / deprovisioning / role mapping | VN-06 SCIM Provisioning | Delivered (runtime-lite) |
| OneProtect internal ticketing + alert triage | VN-07 Internal Ticketing & Alert Triage | Delivered |
| Minimal SIEM: log ingest, normalized search, rules | VN-08 SIEM Log Ingest & Search | Delivered (minimal) |
| macOS 13+ agent + Intune / M365 device posture | VN-09 macOS Endpoint & Intune Posture | Delivered |
| Multi-tenant isolation + tenant admin onboarding | VN-10 Multi-Tenant Isolation & Onboarding | Delivered |
| Phase 1 outbound webhook delivery | VN-11 Outbound Webhook Delivery | Delivered |
| Per-tenant encryption keys (platform-managed) | VN-12 Per-Tenant Encryption Keys | Contract-designed |
| Platform engineering discipline: AWS IaC, CI/CD, OIDC (§5 constraints) | VN-13 Platform Engineering Discipline | Delivered (SBOM/SAST/SCA scheduled in client repo) |
How each capability is proven (portal vs Swagger)
Phase 1 is API-first by the client's own architectural constraint — "every UI capability is backed by a documented, authenticated API; no UI-only features; OpenAPI 3.x is a versioned deliverable." So each capability is proven by the lightest honest artifact, and notes fall into two buckets:
- Portal journey (Bucket A) — capabilities an operator/auditor operates daily. Validate by a live console walkthrough. VN-01, VN-02, VN-04, VN-05, VN-07, VN-10.
- API / Swagger (Bucket B) — real, contract-frozen, tested capabilities driven by an API, IdP, or integration. Validate with Swagger "Try it out" → payload → response, plus the frozen contract and the test. VN-03, VN-06, VN-08, VN-09, VN-11, VN-12. (Several also expose a portal config form, noted in the page.)
- Repo / pipeline review — platform engineering discipline (IaC, CI/CD, keyless OIDC cloud federation). VN-13 — verified by reading the repo + CI config and the AWS plan output, not the portal.
Open Swagger UI at /api/docs (the OpenAPI deliverable), click Authorize and
paste a bearer token for the role the note asks for, then follow that note's
"Validate via Swagger" steps. VN-08 is a hybrid: ingest a log via the real
API, then watch the rogue-device alert → evidence → auditor chain in the portal.
The full Phase-1 → Phase-2 boundary for each is in
docs/planning/phase1-ga-scope-and-evidence-map.md.
Glossary
A few terms recur across the notes. You do not need any others.
- Tenant — one customer organization. All data is isolated per tenant.
- Tenant admin — the customer's administrator; manages users, tokens, and configuration for their own tenant only.
- Operator — a day-to-day user who triages alerts, runs sessions, and works tickets.
- Auditor — a read-only role with time-boxed access; can read redacted evidence and request exports, but cannot change anything.
- Agent — the small program installed on a tenant's machine that reports the machine to OneProtect.
- Enrollment token — a one-time secret a tenant admin generates so an agent can register securely. Shown once.
- Asset — a machine or device that OneProtect knows about (usually because an agent reported it).
- Heartbeat — the regular check-in the agent sends so the asset stays current.
- JIT (just-in-time) grant — a short-lived, time-boxed permission to open a session, created on demand.
- Audit trail — the tamper-evident log of who did what, visible on the Audit page.
- Redaction — hiding sensitive values (passwords, keys, PII) from views and exports.
- Tenant isolation — the guarantee that one tenant can never see another tenant's data.
- Control plane vs. data plane — the control plane authorizes and records an action; the data plane carries the live bytes (for SSH, the keystrokes and output).
- Runtime-lite — a Phase 1 implementation that delivers the working capability while a heavier production mechanism (e.g., enforced mTLS) is deliberately deferred.
What is intentionally deferred (whole-platform)
These were explicitly placed outside Phase 1 in the client response document. Do not fail any deliverable for these:
- Remote desktop, file transfer, patch/software deployment
- Unbounded active scanning and full network topology mapping
- Machine-learning anomaly detection and a full SIEM query/correlation engine
- External ticketing connectors (Jira, ServiceNow, Freshdesk, Zendesk, HaloPSA)
- Bring-Your-Own-Key (BYOK) beyond platform-managed keys
- Azure failover