Why Every Write Is a Patch

In EKOM, there is no code path from a chat message to a production catalog write. Every change — whether initiated by an agent, a user, or an automated policy — goes through the Patch system.

A Patch is a structured object:

• Field diffs: What changed (before/after for each attribute)
• Reason code: Why it changed (schema_fix, missing_attr, clarity, compliance)
• Risk level: Low, medium, or high
• Confidence score: How confident the agent is in the proposed value
• Status: Proposed → approved → deployed (or rejected / rolled back)
• Rollback pointer: Link to the previous version

Why patches instead of direct edits?

1. 1.Reversibility. Every patch can be rolled back. If an agent fills "material" with "polyester" and it should have been "nylon," you revert the patch. The previous value is restored. No guessing.

1. 1.Audit. Enterprise brands ask "what changed?" Every patch is an audit event. Who proposed it, who approved it, when it deployed, what the previous value was.

1. 1.Batching. Patches group into batches. A job that processes 200 products creates a patch batch. You can approve the entire batch, reject it, or approve individual patches.

1. 1.Policy enforcement. Before a patch is generated, the system checks active policies. If "titles" are protected, no patch will propose a title change. Policies are checked at generation time, not after the fact.

1. 1.Staged deployment. Patches can be previewed (diff view) before deployment. Sandbox mode shows what *would* change without actually changing it.

The key insight: Making the atomic unit of work a Patch — not a direct edit — means every downstream system (approval, deployment, audit, rollback) gets the same structured object to work with. It's the contract between agents and the catalog.

This is a deliberate architectural constraint. It makes the system slower than "just write to Shopify" — but it makes it safe, auditable, and reversible. For production catalog data, that tradeoff is correct.