HomeTrust & Security
Trust Architecture
Trust Model
Structural constraints, not trust assumptions.
Fail-closed · Minimal disclosure · Append-only history · Signed responses
308+
Automated Security Tests
All passing
DENY
Default Posture
Fail-closed by design
5
Anti-Spam Layers
Defence in depth
5-Layer Anti-Spam & Security Architecture
🛡️
L1Invisible Bot Detection
Automated challenge layer — blocks bots before they reach the server
🔍
L2Behavioural Traps
Passive detection mechanisms that identify non-human interaction patterns
📧
L3Email Domain Validation
Rejects throwaway and suspicious email domains to prevent abuse
⚡
L4Adaptive Rate Limiting
Per-client request throttling on APIs and forms, with escalating backoff
🔒
L5Schema-Strict Validation
Server-side input validation — rejects malformed or injected data
Active Security Headers
Strict-Transport-Security
HSTS with preload (2 year max-age)
Content-Security-Policy
Strict CSP with nonce-based scripts
X-Frame-Options
DENY — prevents clickjacking
X-Content-Type-Options
nosniff — prevents MIME sniffing
Referrer-Policy
strict-origin-when-cross-origin
Permissions-Policy
Camera, mic, geolocation all denied
Assurance & Compliance
SOC 2 Type II is in progress (target Q3 2026). Until then, we provide bridge artifacts for procurement and security review.
Pen test report (under NDA)
Control summary / readiness letter
SIG Lite / security questionnaire responses
Subprocessors list
DPA available on request
Incident response + vuln management overview
Global compliance readiness
We operate globally and support region-specific requirements via contractual terms, security controls, and evidence packs. We only claim what we can evidence.
Data hosting: Tier-1 cloud infrastructure (regions available on request). Data residency options are programme-dependent.
Last updated: March 2026
Core Principles
Fail-closed by default
If verification cannot be performed, the response is NOT VERIFIED. Systems block or escalate—never assume validity.
Minimal disclosure
Prompts, logs, and PII are excluded by default. Programme-gated access available for authorised verifiers.
Signed responses
Programme-scoped cryptographic verification. Hardware key management options planned for high-assurance programmes.
Append-only history
Withdrawal changes current validity but does not erase history. The audit trail remains for disputes and regulators.
Security Model
Defence in depth with cryptographic verification and auditable access.
TLS 1.3 for all verification requests
Programme-scoped API authentication
Auditable access trail for all lookups
Signed responses with authority reference
Non-exportable keys (HSM/TPM available on request) for high-assurance programmes
Rate limiting and abuse detection
Geographic redundancy for availability
Regular third-party security assessments
Vulnerability disclosure
If you believe you've found a security issue, email [email protected]. We support coordinated disclosure.
Privacy Model
Proof ≠ payloads. Verification proves validity without exposing sensitive data.
Default exclusions
PromptsSystem logsPIIInternal identifiersRaw payloads
What's included by default
stamp_idstatusscope_summaryexpires_atverified_atsignerversionverify_url
Programme-gated access
Extended fields for authorised verifiersAuditor access routesRegulatory disclosure support
Minimal Disclosure by Design
Default verification returns only what counterparties need to make a decision:
stamp_id: GP-STAMP-XXXX-XXXX
status: VALID
scope_summary: hardship_determination
expires_at: 2026-06-15T00:00:00Z
verified_at: 2026-01-19T14:32:00Z
signer: guardian_panel_uk_01
version: 2026.01.19.1
verify_url: https://verify.goodproof.mindchill.ai/GP-STAMP-XXXX-XXXX
Extended disclosure requires programme-gated access. All access requests are logged.
Signed Responses
For high-assurance programmes, verification responses are cryptographically signed:
- •Programme-scoped signing authority
- •Non-exportable keys (HSM/TPM on request where required)
- •Verifiable by counterparties and auditors
How Good Proof works with runtime accountability engines
Good Proof runs standalone today and is designed to ingest evidence from external runtime accountability engines in a future release.
Evidence will be normalized into a common schema regardless of source. Start with Good Proof as your primary verification layer and integrate external engines as requirements evolve—or vice versa.
Standalone operation
Good Proof provides complete scope-limited verification without external dependencies. No integration required to start.
Engine integration
Planned: ingest evidence from external runtime engines through a stable adapter interface. Common Evidence Schema and conformance tests are in design.
Independent witness and quorum model
High-risk reliance should not depend on a single reviewer. Good Proof is designed for random Guardian assignment with configurable quorum thresholds — multiple Guardians will independently review the same evidence before a stamp can issue.
Quorum by risk class
Higher-risk lanes will require larger Guardian panels. Panel size is configured per lane during the Stamp Sprint. Guardians will be randomly assigned to prevent familiarity bias.
Conflict resolution
When witnesses disagree, escalation rules will determine the resolution path. Conflicts will be logged with full audit trail.
Tamper-evident trail
Every attestation, withdrawal, and status change is logged immutably. The audit trail remains for disputes and regulators.
Reliance boundaries by status
Good Proof is scope-limited verification, not blanket certification.
| Status | Action |
|---|---|
VALID | Proceed within approved scope and evidence window. |
NEEDS_REFRESH | Pause and re-verify before action. |
WITHDRAWN | Stop reliance and trigger incident workflow. |
NOT_VERIFIED | Fail closed: block or escalate. |
What risk is reduced
- Decision-time accountability is captured and verifiable.
- Scope boundaries and expiry are enforced at the gate.
- Revocation propagates to all relying parties via Status Link.
- Evidence is exportable for dispute resolution and audit.
What remains out of scope
- Underlying claim file truth or model correctness.
- Raw PII contents or data accuracy.
- Regulatory compliance or legal guarantees.
- Outcome correctness beyond scope boundaries.
Evidence portability and customer control
Good Proof is scope-limited verification, not blanket certification. We design for portability and customer control to mitigate central verifier concentration risk.
Resilience
Geographic redundancy and fail-closed behavior ensure verification remains available. If unreachable, systems block or escalate—never assume validity.
Portability
IDA Evidence Packs will be exportable and self-contained. Customers will be able to archive, migrate, or present evidence independently of Good Proof infrastructure.
Independent verification
Signed responses will be verifiable by counterparties and auditors without contacting Good Proof. Public keys will be distributed via enterprise onboarding packages, embedded in IDA Evidence Packs, and published through multiple independent channels including DNS and the well-known endpoint.
Fail-closed behavior
If verification cannot be performed, the response is NOT_VERIFIED. Systems block or escalate based on lane policy—never proceed on assumption.
Ready to implement?