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. Elevated access is restricted to authentication bootstrap only — all business data operations run on the authenticated user path.
What this means for you
Your sites, decision records, and configuration are only readable and writable by your account. No internal operation accesses your data outside the authenticated path.
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.