NOTICE VERSION · 2026-09-05.V3

Pilot data.
Bounded by evidence.

This notice describes how contact and deployment-control data is intended to be handled when an enterprise representative prepares a codecr VPC sandbox request or optionally requests the two-message onboarding sequence.

[ 01 / PRIVACY NOTICE ]

Who controls the data.
Why it is processed.

Last updated: 5 September 2026. This website copy is an evidence-scoped implementation draft and does not replace counsel’s determination of controller roles, lawful bases, international-transfer safeguards, or jurisdiction-specific duties.

DATA CONTROLLER

codecr Enterprise AI

Physical postal address
[Insert Corporate Headquarters Address Here]
Privacy contact
privacy@codecr.org
DPO / EU representative
[INSERT IF APPLICABLE]

Release blocker: the supplied controller name should be confirmed as the responsible legal entity, and the bracketed headquarters placeholder must be replaced by a valid postal address before production email is enabled.

SCOPE

Enterprise pilot administration and optional onboarding email.

This notice applies to the local pilot preflight, a submitted sandbox request, consent verification, the two-message onboarding sequence, provider delivery events, and suppression. It does not alter the separate source-code processing terms for an authorized codecr deployment.

The local website preflight remains usable without an email address and without consenting to the sequence.

DATA WE EXPECT

Minimized control metadata.

  • Work email and locale, if provided.
  • Opaque preflight, consent, message, and recipient references.
  • Deployment topology, identity provider, repository scope band, and policy preset.
  • Notice version, source URL, affirmative action, confirmation, withdrawal, and suppression timestamps.
  • Delivery, bounce, complaint, unsubscribe, security, and abuse-prevention events.
DATA WE EXCLUDE

No source in email systems.

  • Source code, pull-request diffs, prompts, embeddings, secrets, credentials, and repository contents.
  • Personal data in provider analytics tags, categories, or custom arguments.
  • Authentication tokens in URLs, logs, support forms, or message templates.
PURPOSE + PROPOSED BASIS

Purpose-limited processing.

  • Pilot administration and requested pre-contract steps: GDPR Article 6(1)(b), where applicable.
  • Optional two-message onboarding: consent under Article 6(1)(a).
  • Security, abuse prevention, and audit: legitimate interests under Article 6(1)(f), subject to a documented balancing test.
  • Compliance and suppression evidence: Article 6(1)(c) or 6(1)(f), as counsel confirms.
PROPOSED RETENTION SCHEDULECOUNSEL APPROVAL REQUIRED
Unconfirmed requestVerification lifetime + 24 hours

Expire the token, purge the recipient address, and retain only non-identifying abuse-control evidence where necessary.

Confirmed pilot contactPilot term + 30 days

Retain only the contact and control metadata required to administer, close, or audit the request.

Consent evidenceProposed: 3 years after last message

Retain the notice version, purpose, timestamps, source, confirmation evidence, and withdrawal state; counsel must approve the final period.

Security logsProposed: 90 days

Exclude message bodies and source data; extend only under an approved incident or legal-hold procedure.

Suppression recordWhile needed to honor the opt-out

Keep the minimum opaque or hashed recipient reference, scope, reason, and timestamp; review annually, but do not delete if deletion would permit an unwanted resend.

LIVE SUPPRESSION ENDPOINT POLICY

Opt-out is a write-before-send control.

The production gate requires POST /v1/email/suppressions and the one-click route POST /email/unsubscribe/{single_use_token} to be live, durable, monitored, and idempotent before any onboarding message is enabled.

  • Return 204 No Content whether a valid request creates the suppression or finds it already present.
  • Apply unsubscribe, hard bounce, complaint, withdrawal, or pilot cancellation before evaluating the next queue item.
  • Do not require login, charge a fee, request additional personal data, or use the endpoint for behavioral tracking.
  • Never auto-resubscribe. A new, explicit double opt-in is required to reverse a suppression where legally permitted.
  • Expose a monitored control that proves every send performs a suppression lookup immediately before provider submission.
YOUR CONTROL

Access, correct, delete, restrict, object, port, or withdraw.

Where the GDPR applies, you may request access, correction, erasure, restriction, portability, or object to processing. You may withdraw consent at any time without affecting processing that occurred before withdrawal, and you may lodge a complaint with your competent supervisory authority.

Submit requests to privacy@codecr.org. Identity verification will be proportionate to the request and will not require credentials or source code.

RECIPIENTS + TRANSFERS

Provider choice remains uncommitted.

The selected Tier-1 email provider will act under written data-processing terms and a reviewed subprocessor record. Before activation, codecr must document processing regions, access roles, retention, incident duties, and any required Standard Contractual Clauses or other transfer mechanism.

No provider is authorized by this page. The runtime is currently configured to send nothing.

AUTOMATED DECISIONS

No legal or similarly significant decision.

Email consent, delivery, and suppression automation does not make a solely automated decision producing legal or similarly significant effects. Security automation may stop a message from sending; a human-controlled channel remains available for the underlying pilot request.

CHANGES + SECURITY

Version every material notice change.

codecr will protect the service with access control, encryption, signed requests, replay defense, audit logging, and data minimization. A material change to purpose or consent requires a new notice version and, where required, renewed affirmative consent.

[ 02 / PROVIDER ACTIVATION ]

Authenticate the sender.
Keep the switch open.

Select exactly one provider path. Provider-generated DNS values must be copied verbatim from the verified-domain screen; placeholders below are structural contracts, never production values.

01 / .ENV.PRODUCTION CONTRACT

Inject server-side only.

EMAIL_SYSTEM_STATE=fail-closed
EMAIL_SEND_ENABLED=false
EMAIL_PROVIDER=resend|sendgrid
EMAIL_PROVIDER_SECRET_KEY=__SECRET_MANAGER_VALUE__
WEBHOOK_SIGNING_SECRET=__MINIMUM_32_RANDOM_BYTES__
PROVIDER_WEBHOOK_VERIFICATION_KEY=__PROVIDER_VALUE__
SUPPRESSION_API_ENDPOINT=https://api.codecr.org/v1/email/suppressions
EMAIL_SENDING_DOMAIN=mail.codecr.org
EMAIL_FROM="codecr Enterprise Operations <onboarding@mail.codecr.org>"
EMAIL_REPLY_TO=privacy@codecr.org
EMAIL_CONSENT_NOTICE_VERSION=2026-09-05.v3
DOUBLE_OPT_IN_REQUIRED=true
CONTROLLER_IDENTITY="codecr Enterprise AI"
CONTROLLER_POSTAL_ADDRESS="[Insert Corporate Headquarters Address Here]"
Download .env.production template
02 / FAIL-CLOSED SWITCH

Prove every dependency.

  1. Create scoped provider credentials in the production secret manager; never in Git, client JavaScript, build logs, or Cloudflare DNS.
  2. Bind secrets to the email adapter workload only, restart by immutable deployment, and prove logs redact values.
  3. Verify the dedicated sending domain, DKIM, SPF, DMARC monitoring, signed provider webhook, durable suppression store, and monitored reply mailbox.
  4. Run seed-list delivery, signature-failure, replay, bounce, complaint, and one-click unsubscribe tests.
  5. Replace the headquarters placeholder and attach Legal, Security, and SRE approval to notice 2026-09-05.v3; only then permit the transition to active.
ANY FAILED GATE → EMAIL_SEND_ENABLED=false
DNS AUTHENTICATION / MAIL.CODECR.ORGCLOUDFLARE · DNS ONLY

Use the dedicated visible From domain mail.codecr.org. Preserve existing mail records, publish exactly one SPF record per hostname, and do not activate both provider paths. Cloudflare proxying must be off for every email DNS record. Account-specific DKIM keys and SendGrid account targets do not exist until the provider creates the domain; copy those values verbatim rather than substituting an example.

Email provider DNS authentication records
PATHTYPENAMEVALUE
Resend SPFTXTsend.mailv=spf1 include:amazonses.com ~all
Resend MAIL FROMMXsend.mailfeedback-smtp.us-east-1.amazonses.com · priority 10
Resend DKIMTXTresend._domainkey.mailp=[EXACT PUBLIC KEY GENERATED FOR THIS RESEND DOMAIN]
SendGrid return pathCNAMEem[PROVIDER ID].mailu[ACCOUNT].wl[REGION].sendgrid.net.
SendGrid DKIM 1CNAMEs1._domainkey.mails1.domainkey.u[ACCOUNT].wl[REGION].sendgrid.net.
SendGrid DKIM 2CNAMEs2._domainkey.mails2.domainkey.u[ACCOUNT].wl[REGION].sendgrid.net.
Provider-neutral DMARCTXT_dmarc.mailv=DMARC1; p=none; rua=mailto:dmarc@codecr.org; adkim=r; aspf=r; pct=100
ENFORCEMENT ORDER

Monitor: keep p=none for 14–30 days and review aggregate reports.

Contain: move to p=quarantine only after all legitimate sources align.

Reject: move to p=reject only after Legal/Security approval and clean reports. Never weaken alignment to hide a bad sender configuration.

SIGNED PROVIDER EVENTPOST /V1/EMAIL/PROVIDER-EVENTS

Verify the raw body before JSON parsing. For Resend, require svix-id, svix-timestamp, and svix-signature. For SendGrid, verify the signed Event Webhook with the configured ECDSA public key or approved OAuth control.

Content-Type: application/json
svix-id: msg_...
svix-timestamp: 1788631200
svix-signature: v1,...

{
  "schema_version": "1.0",
  "provider": "resend | sendgrid",
  "provider_event_id": "evt_opaque",
  "provider_message_id": "msg_opaque",
  "event": "delivered | bounced | complained | unsubscribed",
  "occurred_at": "2026-09-05T18:05:00Z",
  "recipient_ref": "recipient_opaque",
  "preflight_id": "pilot_01J..."
}
AUTHENTICATED SUPPRESSIONPOST /V1/EMAIL/SUPPRESSIONS

Require a narrowly scoped service token and idempotency key. Store the suppression before acknowledging a provider complaint, hard bounce, unsubscribe, pilot withdrawal, or cancellation.

Authorization: Bearer <email:suppress token>
Content-Type: application/json
Idempotency-Key: sup_<recipient_ref>_<reason>
X-Request-ID: req_01J...

{
  "recipient_ref": "recipient_opaque",
  "scope": "vpc_sandbox_onboarding",
  "reason": "unsubscribe | complaint | hard_bounce | withdrawal",
  "source": "one_click | provider_webhook | operator",
  "requested_at": "2026-09-05T18:10:00Z",
  "notice_version": "2026-09-05.v3"
}
RESPONSE CONTRACT
202

Consent requested with affirmative_action=true; verification is pending.

204

Unchecked/absent consent, accepted provider event, duplicate event, created suppression, or already-suppressed recipient.

400

Malformed body, unsupported event, or invalid content type.

401 / 403

Missing or invalid signature; missing token; or insufficient email:suppress scope.

413

Payload exceeds 256 KiB. Do not parse or log it.

429 / 503

Rate limit or temporary dependency failure. Provider may retry with bounded backoff.

03 / CONTROLLED STATE TRANSITION

Deploy closed. Prove controls. Activate once.

Run this only from the private Cloudflare Worker repository that serves api.codecr.org. It rejects placeholders, validates live SPF/DKIM/DMARC, requires a durable write-before-send suppression service, injects secrets without printing them, deploys with sending still disabled, and then requests the audited transition.

chmod 0700 activate-codecr-email-funnel.sh
./activate-codecr-email-funnel.sh /secure/path/.env.production

# Required terminal result:
PASS: codecr onboarding email state is active; double opt-in remains mandatory.
IMPLEMENTATION ARTIFACTEmail activation contract

Provider-neutral JSON containing runtime variables, DNS record shapes, endpoint paths, response codes, and the optional-consent state machine.

Download activation contract (.json)

Release boundary: this is the required operational contract, not evidence that provider credentials, DNS records, an API origin, or a production suppression store currently exist. Email remains disabled until the completion record proves every gate.