Docs
These are published engineering constraints on signal-handling-critical code paths. They exist so customers know what GPCGuard will not change without deliberate, evidenced process — and what that means for their operational posture. They are engineering commitments, not legal opinions or compliance guarantees.
We will not change the ordered fail-closed guard chain without explicit migration criteria and verification evidence.
What this means for you
The decision path your site depends on will not change silently. Any modification requires documented evidence and migration criteria.
We will not bypass the dual-client boundary in the customer API. Service-role access is restricted to Supabase Auth token validation; customer data operations run on the authenticated user path with RLS or auth.uid-scoped database functions.
What this means for you
Your sites, decision records, and configuration are only readable and writable by your account. Internal evidence functions derive ownership from your session, not caller-supplied account IDs.
We will not enable policy learning auto-apply by default. Rollout requires explicit criteria, regression gates, and staged evidence.
What this means for you
Decision behavior will not change automatically due to learning system updates. Changes require explicit operator criteria — your signal-handling posture stays predictable.
We will not intentionally log plaintext PII or secrets in signal-processing paths. Structured logs are redacted by design.
What this means for you
Personal data processed during GPC signal evaluation is not written to logs in plaintext. Logs capture decision outcomes, not user identifiers.
For questions about these constraints, custom contractual commitments, or enterprise agreements, contact us.