Compliance OS checks, in a real browser, that the consent behavior your privacy reviewer approved is still what your live site does after releases, template changes and tag-manager edits. When it drifts, one finding gets one owner, one evidence trail and one retest before closure.
A privacy reviewer can approve the banner in March. By May, a template change, GTM edit, vendor update, consent-mode configuration or load-order change can make the live site behave differently, without anything looking obviously broken.
The banner is visible, but a script or request occurs before the reviewed state says it should.
A visitor changes their choice, but reload or navigation does not produce the expected behavior.
A scanner finishes and shows green even though embedded contexts, service workers or downstream behavior were never observed.
Bounded claim: a browser observation proves what that controlled browser saw. It does not prove what a vendor later did with a network request, determine a visitor's legal jurisdiction or issue a legal compliance certificate.
Your reviewer records the approved purpose/vendor treatment, selected jurisdiction, consent-manager profile and the test cases that must be observed.
Initial arrival, reject, selective grant, full grant, reload, navigation, withdrawal and relevant signal combinations run in a real browser.
Expected behavior, observed behavior, reproduction steps, affected release, coverage, limitations and evidence stay together.
The finding does not disappear because someone clicked Resolve. The same expectation is tested again and the retest becomes the closure evidence.
A specific approved record for the site instead of a universal “compliance score”.
Works with the existing consent manager instead of forcing a banner replacement in the first pilot.
Sentinel observes scripts, requests and accessible storage across the configured visitor paths.
Each discrepancy carries release context, evidence, ownership and a proof-based closure path.
Query strings are stripped and cookie evidence is reduced to names so the proof store does not become a new personal-data lake.
Inherited family primitives support isolation, controlled access and an activity trail without rebuilding enterprise foundations per product.
The edge safety layer has expiry, rollback and failure tests, but it does not yet hold scripts back on the page.
Purpose-level state, vendor/purpose evidence and lifecycle records are enterprise-depth work still to be completed.
Production treatment changes are planned to bind to exact releases, stage gradually and fail to a reviewed safe state.
Approved Google Consent Mode behavior, GPC and other versioned privacy signals belong behind explicit protocol and evidence contracts, not vague “all standards supported” claims.
Script execution, network requests, accessible storage, banner state, reload/navigation behavior and configured withdrawal paths in the supported browser profile.
Redirects, embeds, service workers and special contexts when the test profile can reach some, but not all, of the behavior.
Downstream vendor processing, deletion inside third-party systems, legal jurisdiction or lawful basis are never guessed from browser traffic.
Runs the browser paths, captures evidence and verifies the retest. Compliance OS does not mark its own homework.
Owns the reviewed treatment expectation, consent meaning and discrepancy interpretation.
When both are installed, CRO OS can use the reviewed privacy decision before assigning a visitor. Neither product depends on the other.
Shared engine: evidence, approvals, release identity, audit, scoped credentials and recovery are inherited family capabilities. Inherited code is still tested in the Compliance OS context before it counts as product proof.
That is the investor-scale scope. Against the narrower v4 pilot gates, Compliance OS is about 77% built and Gate A, the useful-observation product, is complete on the test site. Since 5 October 2026 it has been running live on our own Lab site, and its first check found a real issue: Cloudflare's analytics sending data before any visitor could choose. The next proof is a reviewed pilot on a customer's site.
Best fit: a web team or agency responsible for several commercial sites, with an engineering owner, an existing consent manager and access to a privacy reviewer.
The first pilot avoids sensitive-data journeys, services directed at children, advertising-auction infrastructure, authenticated personalization, and price or checkout changes.
The pilot is the product proof. It is not a legal certification and it does not silently replace your existing consent manager.
Not in the first product. It observes an existing consent manager and compares live behavior with a reviewed expectation. Replacement/enforcement is a later gate.
Not necessarily. Approved modes such as Google Consent Mode can have different observable behavior. Compliance OS must test the configured mode rather than assume every denied state means absolute network silence.
No. The product records reviewed expectations and verifies implementation. Your privacy/legal reviewer remains responsible for legal interpretation, wording, purposes, vendors and deployment scope.
A retest against the reviewed expectation. Time passing or a manual “resolved” click is not enough.
The observation workflow has been exercised with a real Klaro banner on a test site, including planted drift cases, and has run live on our own Lab site since 5 October 2026. A reviewed pilot on a customer's site, formal Gate B safety proof and production enforcement remain outstanding.
Start with a baseline. Learn what the live browser actually does. Keep every discrepancy open until the same test passes again.