Source · CMS snapshot (seed) — this guide body is served fromcontent/generated/cms-snapshot.json, not the code catalog alone. Staff path: Content Studio (:3030/experience/sites) → publish guide →MCV_CONSOLE_URL=http://localhost:3030 pnpm --filter @mcv-tech/marketing-shell content:seed→ rebuild:3050. Offline:MCV_CMS_SNAPSHOT_FILE=… pnpm content:seed.
The outcome you are walking toward
A completed review pass: every control domain read in the architecture that enforces it, a short list of things to verify live in the product, and a clear request path for anything that is shared on request rather than published.
1. Read the controls in review order
Start with the boundary everything else depends on: per-brand data isolation — database-enforced, deny-by-default, fails closed. Then identity: Triangle secure sign-on covers the one-credential model and brand-scoped grants. Then approval gates and the audit trail.
2. Ask the questions that separate platform from demo
The questions that matter — data boundaries, exits, approvals, failure posture — are listed in Questions to ask any Business OS vendor. Each one maps to a doc you have just read; where it does not, that gap is what your briefing should cover.
3. Verify live, not on paper
The two checks worth doing in the product: reconstruct one specific action from the audit trail, and confirm brand isolation fails closed on a query that should be denied. Both are standard diligence walkthrough steps — request them rather than taking the docs on faith.
4. Use the request path for the rest
Formal attestations are shared through the diligence process when they exist — they are not badged on public pages before they do. The diligence resources page keeps the full reading path and the briefing request route in one place.