Ecommerce data governance contract¶

This contract applies to source payloads, canonical data, mappings, Odoo readback, operations, warehouse marts, caches, queues, logs, exports, backups, and non-production fixtures.

Classification¶

Class	Examples	Minimum controls
`public`	Published API documentation, non-sensitive schema names	Integrity and release review
`internal`	Aggregate service metrics without tenant/customer identity	Workforce authentication and least privilege
`confidential`	Tenant configuration, pseudonymous commerce facts, mapping metadata	Tenant authorization, encryption, audit, controlled export
`restricted`	Raw source payloads, customer identity/address, financial evidence, Odoo document detail	Need-to-know role, strong encryption, time-bound access, detailed audit, retention policy
`secret`	Source/Odoo API keys, webhook secrets, database/object credentials	Secrets manager only; never business database, queue, logs, exports, or fixtures
`prohibited`	CVV, full magnetic-stripe data, authentication passwords, unnecessary full PAN	Must not be intentionally collected or stored

Detection of prohibited data quarantines the payload, blocks downstream use, alerts security, and follows the data-incident runbook.

Data inventory¶

Data product	Default class	System of record	Allowed purpose
Connection metadata	Confidential; secret references only	Platform PostgreSQL	Provisioning, health, audit
Raw source payload	Restricted	Encrypted object storage	Replay, evidence, adapter repair
Ingestion envelope/hash	Confidential	Platform PostgreSQL	Deduplication, lineage, operations
Canonical commerce	Confidential/restricted by field	Platform PostgreSQL	Workflow, accounting policy, reconciliation
Posting intent/operation	Restricted financial evidence	Platform PostgreSQL	Approval, idempotency, audit, recovery
Odoo readback snapshot	Restricted financial evidence	Platform/object storage	Mutation verification, reconciliation
Warehouse facts/marts	Confidential; pseudonymous	Warehouse	Reporting and analytics
Export	Inherits highest source class	Controlled object storage	Approved user purpose
Logs/traces	Internal/confidential	Observability platform	Operations; no raw payloads/secrets
Backups	Inherits contained classes	Backup system	Disaster recovery only

Every field in executable schemas carries a classification tag, purpose, retention class, and redaction behavior. Schema CI rejects new unclassified restricted-looking fields.

Minimization¶

Select only source streams and fields required by approved workflows and metrics.
Do not ingest card PAN/CVV, passwords, or unrelated marketing/content/customer-history data.
Store customer name/address/contact fields only where invoice, tax, fulfillment, support, or evidence requirements justify them.
Use stable pseudonymous customer tokens in warehouse dimensions and analytics.
Keep source payload references out of normal UI and reporting responses.
Detailed Odoo records remain on demand unless a documented projection/reporting requirement exists.
Logs contain IDs, hashes, sizes, timing, status, and stable errors, not payload bodies.

Access model¶

Role	Raw payload	Canonical detail	Financial evidence	Marts	Export
Client viewer	No	Tenant-scoped safe view	Tenant-scoped safe view	Tenant only	Approved reports
Staff preparer/reviewer	Time-bound case access	Assigned tenants	Assigned cases/tenants	Authorized portfolio	Purpose-bound
Integration engineer	Time-bound support access	Technical fields	Redacted by default	Health marts	No customer export by default
Security/privacy	Incident or request scope	As required	As required	Audit views	Controlled evidence
Platform service	Minimum machine scope	Workflow-specific	Workflow-specific	Serving views	No interactive export

Restricted break-glass access requires step-up authentication, reason, incident/case ID, short expiry, immutable audit, and post-access review.

Encryption and key management¶

TLS is required for source, Airbyte, Odoo, API, database, object-store, queue, and observability transport.
Databases, object storage, exports, backups, and queue storage use managed encryption at rest.
Raw payloads and exports use tenant-aware envelope encryption where supported.
Secrets are versioned and rotated in the secrets manager; business tables store only opaque references.
Key rotation does not require rewriting business identity or changing operation idempotency keys.
Encryption/key access is separated from ordinary application database ownership.

Retention policy¶

Retention is effective-dated and approved by legal, privacy, security, and accounting owners. The values below are pilot operational defaults, not universal statutory advice.

Retention class	Pilot default	Disposition
`raw_replay`	90 days after successful canonicalization	Delete payload; retain safe hash/lineage if permitted
`webhook_delivery`	30 days after terminal processing	Delete body; retain delivery ID/status/hash
`operational_event`	400 days after terminal state	Archive/delete according to policy
`financial_evidence`	Tenant/jurisdiction policy; no automatic default	Restrict/archive until approved expiry
`mapping_policy_history`	Policy life plus approved audit period	Archive; preserve versions used by retained evidence
`warehouse_detail`	Approved reporting horizon	Delete or aggregate; preserve controls where required
`observability`	30-90 days by signal/class	Delete; security incidents may enter legal hold
`export`	Seven days unless purpose requires less/more	Delete object and revoke signed links
`backup`	Defined backup cycle	Expire cryptographically/physically under backup policy

Retention starts from the domain-defined terminal or evidence date, not ingestion time when that would prematurely delete required evidence. Legal hold and incident hold override deletion and are audited.

Data subject and correction handling¶

Authenticate the requester and establish tenant/subject scope.
Search the subject index, not unrestricted raw payload scans from a browser request.
Classify each result as erasable, correctable, restrictable, or retained under an approved obligation.
Apply deletion/restriction to operational stores, marts, search indexes, caches, exports, and future rebuild inputs.
Preserve non-identifying operation/accounting integrity where lawful by replacing direct identifiers with restricted tokens.
Record decision, legal basis/owner approval, systems affected, completion evidence, and backup propagation behavior.

Posted Odoo accounting records are corrected through approved Odoo/legal workflows, not database deletion. Accountify does not silently rewrite Odoo legal documents.

Exports¶

Exports are asynchronous resources with:

export_id
tenant_id and authorized scope
requester and purpose
query/filter hash
classification
row count and content hash
generated_at and expires_at
download count
revocation/deletion evidence

Signed download URLs are short-lived and single-purpose. Export generation rechecks authorization and tenant scope; a queued request does not preserve access after a user's permissions are revoked.

Non-production and fixtures¶

Production payloads and customer identity are prohibited in local development and ordinary test environments.
Fixtures are synthetic or irreversibly anonymized and reviewed for prohibited/restricted fields.
Odoo clones used for capability testing follow approved masking and access controls.
Debug dumps, screenshots, HAR files, SQL exports, and dead-letter payloads inherit source classification and retention.
Vendor/support transmission requires approved purpose, minimum necessary data, processor terms, and audit.

Offboarding¶

Tenant offboarding:

Disable new source ingestion and Odoo mutation; revoke/rotate credentials and webhook subscriptions.
Drain or safely classify in-flight operations and preserve unknown-outcome verification.
Produce approved final exports and reconciliation/retention inventory. Where the client's accounting continuity is delivered through a DATEV export archive to their tax advisor, that archive is the authoritative handover record; an Odoo database dump may be offered as a courtesy copy and does not replace approved exports.
Remove interactive access, caches, search indexes, temporary exports, and serving views.
Retain/restrict or delete each data class under the approved policy and legal holds.
Verify object storage, warehouse, queues, observability, backups, and third-party processors.
Record signed completion evidence without retaining secret values.

Lineage and audit¶

Every reportable/postable value is traceable through:

source connection and payload hash
-> ingestion run/inbox record
-> adapter and canonical event/version
-> policy and mapping versions
-> posting intent and operation attempts
-> Odoo readback
-> reconciliation allocation
-> warehouse batch, fact, mart, metric version
-> export or dashboard query

Audit records are append-only, tenant-scoped, time-synchronized, and protected from ordinary application update/delete roles.

Acceptance criteria¶

Field-level schema inventory has classification, purpose, retention, and redaction metadata.
Cross-tenant and unauthorized restricted-data access tests fail across API, SQL, queue, object, cache, search, logs, marts, and exports.
Secrets/prohibited data scanners cover commits, logs, fixtures, dead letters, exports, and object storage.
Retention jobs are idempotent, hold-aware, audited, and tested against mart rebuilds and backups.
Data-subject restriction and tenant offboarding tabletop tests cover every storage/processor class.
A deleted raw payload cannot reappear through a later mart rebuild; retained lineage remains non-identifying where required.