Digital Commerce Compliance Boundaries

When checkout works but “compliance” is still unproven

Imagine a learning marketplace that shows an initial course price, adds a mandatory fee later, processes learner data for checkout and marketing, and offers different cancellation/refund paths across two jurisdictions. The checkout may be technically correct. That fact alone does not prove claim substantiation, price/fee transparency, disclosure adequacy, purpose/consent validity, seller role, or cancellation/refund obligations.

In this lesson we build Digital Commerce Compliance Boundary Matrix & Evidence Ledger v1. Each decision is bound to explicit evidence: jurisdiction, seller_role/marketplace_role, claim_evidence_ref, price_display_state, mandatory_fee_state, disclosure_prominence, consent_purpose/consent_state, privacy_notice_ref, cancellation_path_ref, refund_policy_ref, policy_version, legal_basis_ref, review_owner, and review_state.

Core rule: a working UI, a platform pattern, a generic checklist, or an AI answer is not by itself proof of legal compliance. Incomplete, stale, or conflicting evidence remains REVIEW_REQUIRED, HOLD, or INSUFFICIENT_EVIDENCE. This lesson does not provide legal advice; it designs an auditable evidence boundary that can route uncertainty to qualified review.

For: marketplace/LMS engineers, product engineers, privacy/compliance-aware architects, QA and reviewers. Not for: final legal interpretation, replacing counsel/qualified review, or declaring a real product lawful in a named jurisdiction.

Route orientation and ownership boundary

MKN-026 owns only Digital Commerce Compliance Boundaries. Its authorized prerequisite is MKN-021. MKN-025 owns reputation anti-gaming/trust signals and MKN-027 owns structured authoring UX; this lesson does not absorb either outcome.

Foundation uses a field map and synthetic baseline. Repair isolates the first broken evidence dimension such as fee visibility, consent purpose, or stale legal basis. Experienced learners defend the trade-off among automation, jurisdiction routing, marketplace role, privacy purpose, and human review without flattening them into compliant=true.

Three checkpoints: F1 state the owned boundary and a non-goal; F2 reject one shortcut using the exact field/state; F3 recompute a transfer with a new seller model and jurisdiction only from new evidence.

Mental model: the compliance gate is an evidence router, not a boolean

Reference flow:

commerce surface → jurisdiction + role identification → claim/price/disclosure evidence → consent/privacy purpose → cancellation/refund lifecycle → qualified review → RELEASE / REVIEW_REQUIRED / HOLD

Keep three layers separate:

1. Product behavior: what the system displays, collects, or executes—headline price, mandatory fee, marketing toggle, cancellation path.
2. Evidence and policy/legal references: claim substantiation, disclosure evidence, privacy notice, consent evidence, policy version, and legal_basis_ref, all versioned and traceable.
3. Qualified decision: an authorized reviewer closes interpretation or conflict. AI and application code organize/validate evidence; they do not create legal authority.

RELEASE is an internal bounded state only after all defined gates have sufficient evidence and required review is closed. It must not be interpreted as “this business is legally compliant everywhere.”

Foundation contract: matrix, ledger, and state vocabulary

For each commerce surface keep at least these dimensions:

• identity: commerce_surface_id, offer_id, jurisdiction;
• claims/pricing: claim_id, claim_evidence_ref, price_display_state, mandatory_fee_state, disclosure_id, disclosure_prominence;
• privacy/consent: consent_purpose, consent_state, privacy_notice_ref;
• role/lifecycle: seller_role, marketplace_role, cancellation_path_ref, refund_policy_ref;
• authority/review: policy_version, legal_basis_ref, review_owner, review_state, effective_date, exception_ref, audit_event_id.

Five invariants:

1. Jurisdiction explicit: no row reaches release without a jurisdiction or valid route to qualified review.
2. Evidence before positive state: claims, fees/disclosures, and purpose/consent need traceable references.
3. Role-aware: first-party seller and marketplace/third-party seller are different roles; role mutation requires recomputation.
4. Lifecycle explicit: cancellation/refund fields are separate from checkout success.
5. No AI legal conclusion: AI may flag missing fields or contradictions but may not fabricate legal interpretation.

Preserve non-success states: UNKNOWN, UNVERIFIED, STALE, REVIEW_REQUIRED, HOLD, INSUFFICIENT_EVIDENCE, and REVOKED.

Deep explanation: why each dimension stays independent

Claims and disclosures. FTC official online advertising/marketing guidance states that truth-in-advertising standards apply online and emphasizes meaningful disclosures. That is U.S. guidance, not a universal MAKNOW rule engine. Architecturally, claims and disclosures therefore need explicit evidence and jurisdiction boundaries rather than “a banner exists.”

Price and mandatory fees. Headline price and mandatory-fee presentation are separate evidence dimensions. If a fee moves from the offer screen to final checkout, the interface may still function but price_display_state and mandatory_fee_state must be recomputed. “Checkout succeeded” is not a repair.

Consent and privacy purpose. The NIST Privacy Framework is a voluntary privacy-risk management tool and helps reason about roles in a data-processing ecosystem; it is not law and does not determine a jurisdiction-specific obligation. If purpose expands from fulfillment-only to fulfillment + marketing, old consent/privacy evidence cannot silently carry forward.

Seller/marketplace role. Role affects workflow and review routing. Adding a third-party seller requires recomputation of seller_role, marketplace_role, and related evidence. Platform capability is not proof of an obligation.

Cancellation/refund. Lifecycle obligations are independent fields. If a cancellation path or refund policy is unknown, checkout completion cannot imply a positive release state.

Policy version and legal basis. A legal_basis_ref without version/effective date is unsafe. Stale evidence yields STALE/HOLD. Conflicting jurisdiction or authority evidence routes to qualified review.

FACT / INFERENCE / DESIGN. FTC/NIST provide bounded external facts. Keeping dimensions separate is an architecture inference for auditability. The exact MAKNOW schema, state labels, and review routing are local design authority.

Worked example: two jurisdictions, one fee conflict, one purpose boundary

Use a synthetic baseline. OFFER-COURSE-41 is sold on SURFACE-WEB-CHECKOUT. In JUR-A-DEMO, claim evidence and a disclosure reference exist; the mandatory fee is visible from the first offer view; consent purpose is fulfillment-only; review is still open. In JUR-B-DEMO, legal interpretation intentionally remains REVIEW_REQUIRED. The bounded case result is therefore REVIEW_REQUIRED, not because the software failed but because unresolved authority evidence is preserved honestly.

Table MKN-026-T1 compares baseline, a late-fee mutation, and a transfer with a third-party seller plus new jurisdiction. There is no single compliant=yes column; the decision is derived from evidence dimensions.

Mutation 1: move a mandatory fee to final checkout without updating disclosure evidence. Result: HOLD because fee/disclosure evidence no longer matches behavior.

Mutation 2: expand purpose to fulfillment + marketing while consent evidence still proves fulfillment-only. Result: HOLD; a visible privacy notice or checkbox does not repair contradictory evidence.

Mutation 3: add a third-party seller but reuse first-party role evidence. Fail closed until seller/marketplace evidence and review routing are rebuilt.

Run the deterministic fixture at lab://MKN-026/MKN-026-LAB1.

Failure modes that create false confidence

Generic compliance flag. is_compliant=true without matrix dimensions destroys provenance and must be rejected.

Late fee with old disclosure proof. Behavior changed but the old disclosure reference/version remained. That is stale evidence.

Purpose expansion without consent update. Marketing was added but consent state did not change. A positive result cannot survive.

Old legal basis reused for a new jurisdiction. JUR-C-DEMO is added while legal_basis_ref still belongs to JUR-A-DEMO. This is an identity mismatch.

Seller-role mutation ignored. First-party becomes marketplace but role fields remain unchanged. The workflow must return HOLD/REVIEW_REQUIRED.

Implementation or satisfaction as proof. Conversion, user satisfaction, or “a major platform supports this” is not proof of legal compliance.

AI declares lawful. A model may summarize the matrix and detect missing evidence but may not assert “this flow is legally compliant” without qualified authority.

Review closes unresolved evidence. review_state=APPROVED while legal basis or consent evidence is unknown is a contradiction and must fail.

Experienced bridge: policy-as-evidence, not policy-as-oracle

At scale, the matrix may receive inputs from catalog/pricing, checkout, consent registry, seller registry, policy repository, and review workflow. No single service has complete authority.

A safer architecture separates observed behavior, evidence references, and decision state. A deterministic engine finds contradictions such as fee moved/disclosure unchanged, purpose expanded/consent unchanged, legal-basis jurisdiction mismatch, or stale policy version. Ambiguous interpretation routes to human review.

Each reference carries source identity, version/effective date, and audit event. On a policy update, previous decisions are not overwritten; a new decision with new provenance records what changed.

AI remains an assistant: field extraction, diff, routing suggestions, and completeness checks. It cannot invent authority, fabricate a review owner, or issue a legal conclusion.

Alternatives and trade-offs

Boolean flag is simple but erases provenance and uncertainty; insufficient for this release boundary.

Text-only checklist is useful for onboarding but is not replayable without evidence references, versions, and typed states.

Hard-coded jurisdiction rules can automate more, but without freshness/versioning and qualified ownership they become stale quickly. This lesson does not build a legal rule library.

Evidence matrix + human review routing costs more schema/workflow work but preserves uncertainty and makes decisions auditable; it is the reference pattern here.

External platform defaults may provide implementation hints but are not local authority. Platform support is an evidence input, not permission.

Stop/pivot condition: if the team cannot reconstruct jurisdiction, role, evidence version, and review owner for a decision, weaken the release state rather than hiding uncertainty behind a score or model confidence.

Guided and independent practice

Guided. Open the baseline fixture. For each row identify jurisdiction, seller/marketplace role, claim/price/disclosure evidence, consent purpose, cancellation/refund references, legal basis/policy version, and review owner/state. Then derive the bounded state. If one decisive dimension is missing, a positive state is forbidden.

Repair. Run fee_late_without_disclosure_update. Identify only the invalidated fields and the minimum repair: observed behavior and disclosure evidence must be version-aligned; “add warning text” is not enough without appropriate evidence/authority.

Independent. Solve the purpose-expansion fixture without looking at the baseline state. Explain why fulfillment-only consent is not an oracle for marketing purpose.

Experienced. Run the transfer: add a third-party seller and new jurisdiction. Rebuild seller_role, marketplace_role, privacy purpose, cancellation/refund, legal basis, and review route from scratch. Do not reuse the baseline decision label.

Verification: what counts as proof here?

The lab is offline JSON/CSV with no network, API key, tenant, or customer data. Producer tests must show at least: baseline with unresolved qualified review becomes REVIEW_REQUIRED; late fee, purpose expansion without updated consent, seller-role mismatch, new-jurisdiction/old-legal-basis, missing claim evidence, stale policy version, generic boolean shortcut, AI legal conclusion, missing review owner, and approval with unknown evidence all fail closed; the transfer reaches an independently recomputed review state.

These tests prove only the synthetic evidence-contract logic. They do not prove that a real checkout is lawful in a country, that legal sources are complete, that qualified counsel reviewed the case, or that external policy will not change.

Human verification must reconstruct the bounded decision from visible files and fields. Hidden model chain-of-thought is not evidence.

Assessment and transfer

S1 Retrieval: explain MKN-026's owned boundary and name one non-goal. S2 Application: build the complete baseline Matrix & Evidence Ledger and derive the state from evidence. S3 Diagnosis: move a mandatory fee from first offer screen to final checkout; name the exact invalidated field/state and minimal repair. S4 Transfer: add a third-party seller and new jurisdiction; recompute seller/marketplace role, disclosure, privacy purpose, cancellation/refund, and review obligations from new evidence.

The rubric has five blocking dimensions: identity/contract, exact evidence binding, negative evidence, bounded decision, and transfer. Any answer that treats implementation success or a generic checklist as proof of legal compliance fails.

References, freshness, and claim boundaries

FTC — Online Advertising and Marketing https://www.ftc.gov/business-guidance/advertising-marketing/online-advertising-marketing Bounded FACT: truth-in-advertising standards apply online and material disclosures must be presented effectively. Boundary: U.S. consumer-protection guidance; not a universal MAKNOW compliance oracle for all jurisdictions/product categories.

NIST — Privacy Framework https://www.nist.gov/privacy-framework Bounded FACT: a voluntary framework for identifying and managing privacy risk in products, services, and data-processing ecosystems. Boundary: not law and not a jurisdiction-specific obligation engine. NIST's current site also shows active Privacy Framework 1.1 work, so version/freshness must be recorded.

Official sources were rechecked on 2026-09-13. Legal/policy-current claims must be requalified by 2026-11-12 or earlier after material change; the privacy-framework practice claim must be reviewed by 2027-01-15 or earlier after material change. Accepted canonical bytes require a new version for any change.

Closing question: which shortcut creates the most false confidence in your commerce flow—compliant=true, late-fee disclosure, consent reuse, legal-basis reuse, or AI reliance—and which exact evidence field exposes it?

python run_checks.py fixtures/baseline.json
python run_checks.py fixtures/fee_late_without_disclosure_update.json
python run_checks.py transfer/transfer_fixture.json