@openauditmodel/cli 0.1.0

package/profiles/customer-and-account-management/README.md

@@ -0,0 +1,340 @@
+# Customer and Account Management Profile
+
+**Profile version: 0.1 · Core versions: 0.1 · Status: Experimental · Implemented, 13 rules (12
+enforceable)**
+
+Additional conformance requirements for material **customer** and **business account** lifecycle
+audit events: creating, updating, merging, restricting, closing and deleting a customer record, and
+opening, updating, re-limiting, freezing, restricting, reinstating and closing an account.
+
+```bash
+auditmodel check-profile examples/profiles/customer-and-account-management/valid \
+  --profile customer-and-account-management
+```
+
+The rules live in [profile.json](profile.json) and are enforced by the declarative engine described in
+[profiles/README.md](../README.md). Nothing in this profile is implemented in code.
+
+## Purpose
+
+Customer and account administration is where a business decides who it will deal with and on what
+terms. Freezing an account, restricting a relationship, raising a transfer limit, merging two parties
+or erasing a record are the operations a complaint, a dispute, a fraud investigation or a supervisory
+question later turns on — and they are typically performed by a handful of operators through internal
+consoles that log the least.
+
+The core model already records who did what to which resource. What it cannot know is the small set
+of domain facts that make these particular events reviewable: what kind of party the record describes,
+which account it was, what a restriction actually prevented, what a limit was before and after, which
+record a merge retired, and whether an operator was acting for someone else. This profile requires
+those facts and nothing else.
+
+## Scope
+
+The profile is vendor-neutral. It describes operations that any system holding customers and accounts
+performs — a bank, a telecommunications operator, an insurer, a utility, a marketplace, a SaaS
+billing platform — and assumes no particular product, storage backend, workflow engine, account
+numbering scheme, regulator or jurisdiction.
+
+It governs **business parties and business accounts**. It is not an identity profile: see
+[Cross-profile overlaps](#cross-profile-overlaps).
+
+## Event families
+
+| Family                     | Events                                                                                                      | Governed |
+| -------------------------- | ----------------------------------------------------------------------------------------------------------- | -------- |
+| Customer record lifecycle  | `customer.create`, `.update`, `.merge`, `.close`, `.delete`, `.restrict`, `.restore`                        | yes      |
+| Account lifecycle          | `account.open`, `.update`, `.close`, `.reopen`, `.freeze`, `.unfreeze`, `.restrict`                         | yes      |
+| Account status transitions | `account.status.` prefix (for producers that model transitions as one event rather than distinct verbs)     | yes      |
+| Account limits             | `account.limit.` prefix                                                                                     | yes      |
+| Reads and searches         | `customer.profile.view`, `customer.search`, `account.balance.view`, `account.statement.view`, and their kin | **no**   |
+
+Both shapes of status change are accepted deliberately. Some systems emit `account.freeze`; others
+emit a single `account.status.update` and carry the transition in `change`. The profile requires the
+same facts from both rather than forcing a producer to rename its events, and the fixtures include
+one of each.
+
+`event.category` is left to the producer. A freeze is reasonably `security` in one system and
+`resource-lifecycle` in another, and no rule here inspects the category.
+
+### Explicit exclusions
+
+Ordinary reads are **not governed**: profile views, customer searches, balance and statement lookups,
+transaction listings, entitlement checks, and any other high-volume data-plane traffic. A customer
+platform emits these constantly. Requiring a party type, an owning customer and a justification on
+each of them would add cost to the highest-volume events in the system in exchange for very little
+review value, and the requirement would be switched off rather than met.
+
+The exclusion is **structural, not a matter of discipline**: no selector in this profile uses a bare
+`customer.` or `account.` prefix. The lifecycle families are named event-by-event, and only
+`account.limit.` and `account.status.` — sub-families in which every member is a material change —
+are matched by prefix. `customer.profile.view` and `account.balance.view` therefore match no rule at
+all and `check-profile` reports them as not applicable. A test asserts this, because widening one
+prefix later would silently start governing every profile view in a deployment.
+
+Excluded does not mean unaudited. A view of a customer record is still a conforming OpenAuditModel
+event, and [data-access.md](../../semantic-conventions/data-access.md) covers recording reads —
+including the case, called out there, where a read crosses a customer boundary and deserves more.
+
+## Rules
+
+Twelve rules are enforceable (`error`); `CUSTOMER-CORE-002` is a `warning` and never fails
+conformance.
+
+| Rule                    | Applies to                                                                        | Requires                                                                           |
+| ----------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| `CUSTOMER-CORE-001`     | every governed event                                                              | `/metadata/customer/customerType` string                                           |
+| `CUSTOMER-CORE-002`     | every governed event                                                              | _recommends_ `/reason`, `/request/correlationId`, `/resource/classification`       |
+| `CUSTOMER-ACCOUNT-001`  | every governed `account.*` event                                                  | `/resource/ownerId`, `/metadata/customer/accountType` string                       |
+| `CUSTOMER-CONTROL-001`  | merge, close, delete, restrict, restore, reopen, freeze, unfreeze, limits, status | `/authorization`, `/reason`; _recommends_ `/approval`                              |
+| `CUSTOMER-UPDATE-001`   | `customer.update`, `account.update`                                               | `/change`; _recommends_ `/change/changedFields`                                    |
+| `CUSTOMER-STATE-001`    | status transitions and `account.status.`                                          | `/change`, `/metadata/customer/status` string                                      |
+| `CUSTOMER-RESTRICT-001` | `customer.restrict`, `account.restrict`, `account.freeze`                         | `/metadata/customer/restrictionScope` string; _recommends_ `/approval`, `reviewId` |
+| `CUSTOMER-LIMIT-001`    | `account.limit.`                                                                  | `/change/before`, `/change/after`, `/metadata/customer/limitType` string           |
+| `CUSTOMER-MERGE-001`    | `customer.merge`                                                                  | `/relatedResources`, `/metadata/customer/mergedFromId` string                      |
+| `CUSTOMER-DELETE-001`   | `customer.delete`                                                                 | `/metadata/customer/deletionScope` string; _recommends_ `/approval`, `/privacy`    |
+| `CUSTOMER-APPROVAL-001` | every governed event, **when** `/metadata/customer/approvalRequired` is `true`    | `/approval/status`                                                                 |
+| `CUSTOMER-SUBJECT-001`  | every governed event, **when** `/metadata/customer/onBehalfOf` is `true`          | `/subject`                                                                         |
+| `CUSTOMER-OVERRIDE-001` | every governed event, **when** `/metadata/customer/manualOverride` is `true`      | `/authorization`, `/reason`                                                        |
+
+Each rule's full text and rationale is in [profile.json](profile.json).
+
+## Metadata namespace
+
+Every metadata requirement lives under **`/metadata/customer/`**. Nothing is required at a metadata
+root key: `/metadata/status` or `/metadata/type` would collide with any other profile that governs the
+same event, and a reader would have no way to tell whose `status` it was.
+
+| Field              | Type    | Required by                             | Example                             |
+| ------------------ | ------- | --------------------------------------- | ----------------------------------- |
+| `customerType`     | string  | `CUSTOMER-CORE-001` (every event)       | `business`, `individual`, `partner` |
+| `accountType`      | string  | `CUSTOMER-ACCOUNT-001` (account events) | `settlement`, `subscription`        |
+| `status`           | string  | `CUSTOMER-STATE-001` (transitions)      | `active`, `restricted`, `closed`    |
+| `restrictionScope` | string  | `CUSTOMER-RESTRICT-001`                 | `outbound-payments`                 |
+| `limitType`        | string  | `CUSTOMER-LIMIT-001`                    | `daily-transfer-limit`              |
+| `mergedFromId`     | string  | `CUSTOMER-MERGE-001`                    | `customer-8420`                     |
+| `deletionScope`    | string  | `CUSTOMER-DELETE-001`                   | `personal-data`, `full-record`      |
+| `approvalRequired` | boolean | conditional discriminator               | `true`                              |
+| `onBehalfOf`       | boolean | conditional discriminator               | `true`                              |
+| `manualOverride`   | boolean | conditional discriminator               | `true`                              |
+| `reviewId`         | string  | recommended by `CUSTOMER-RESTRICT-001`  | `review-2026-044`                   |
+
+Every vocabulary above is **open**. The profile requires that a value be recorded and that it be a
+string; it does not say what a customer type, an account type, a status or a restriction scope may be,
+because those are product and organization decisions. A profile that enumerated them would be one
+vendor's field list wearing a domain's name.
+
+## Conditional-policy fields
+
+Three requirements fire only on a discriminator the **producer** sets. This is the whole conditional
+mechanism v0.1 offers — one path compared for equality against one scalar — and it is used here for
+the same reason the IAM profile uses `privileged` and the document profile uses `recipientType`: the
+profile cannot decide these questions for a deployment, but it can enforce the consequence of the
+deployment's own answer.
+
+| Discriminator                         | Consequence                                                     |
+| ------------------------------------- | --------------------------------------------------------------- |
+| `/metadata/customer/approvalRequired` | `CUSTOMER-APPROVAL-001` requires `/approval/status`             |
+| `/metadata/customer/onBehalfOf`       | `CUSTOMER-SUBJECT-001` requires `/subject`                      |
+| `/metadata/customer/manualOverride`   | `CUSTOMER-OVERRIDE-001` requires `/authorization` and `/reason` |
+
+**When the discriminator is absent, the condition does not hold and the rule contributes nothing.**
+That is deliberate and is documented in [profiles/README.md](../README.md): treating a missing flag as
+possibly true would fail every event that never intended to declare one. If an organization wants the
+flag itself to be mandatory, that is a local policy, and this profile does not impose it — an event
+that simply never says `manualOverride` is conforming.
+
+## Approval model
+
+`/approval` is **never universally required**. Customer administration is performed by trained
+operators making single-person decisions in every organization the authors are aware of, and a profile
+that demanded a second approver on every freeze would describe one company's process and be ignored
+everywhere else.
+
+Instead:
+
+- `CUSTOMER-CONTROL-001` **recommends** `/approval` on every restrictive, destructive or
+  limit-changing operation, so its absence is visible as a warning.
+- `CUSTOMER-RESTRICT-001` and `CUSTOMER-DELETE-001` repeat the recommendation for the two operations
+  where a second pair of eyes matters most.
+- `CUSTOMER-APPROVAL-001` **requires** `/approval/status` when, and only when, the producer has itself
+  declared `approvalRequired: true`. An operation the system said needed approval, recorded with no
+  approval state at all, is either an unapproved change or an unrecorded one — and the trail cannot
+  tell which.
+
+The rule requires `/approval/status` rather than `/approval`, so the finding points at the fact that is
+missing rather than at its container. It does **not** require the status to equal `approved`: a
+rejected or expired approval is a legitimate thing to record, and an event that failed for exactly
+that reason must remain expressible.
+
+## Privacy considerations
+
+Customer records are the densest concentration of personal data most systems hold, so this profile is
+deliberately built out of **categories and opaque identifiers**, never people.
+
+- Nothing in the profile requires a name, an email address, a telephone number, a postal address, a
+  date of birth, a national identifier, a payment instrument or an account number. The party is
+  identified by `/resource/id` and `/resource/ownerId`, which are opaque references.
+- `customerType` is a **category** — `business`, `individual`, `partner`. It is what makes an access
+  review answerable and it identifies nobody.
+- `CUSTOMER-UPDATE-001` requires `/change` and recommends `/change/changedFields` precisely so that a
+  producer can record _which_ fields of a customer record changed without recording their values. The
+  core accepts field names, sanitized state, hashes or references, and for this domain field names are
+  usually the right answer.
+- `CUSTOMER-DELETE-001` recommends `/privacy` on erasure, because an erasure event that itself carries
+  the erased data is the worst possible outcome.
+- Account numbers, card numbers and IBANs must never appear anywhere in an event — not in
+  `resource.id`, not in `metadata`, not in `change`. Use an opaque account reference such as
+  `account-ref-781`. `resource.name` is left unused by every fixture in this profile for the same
+  reason: for a customer it is usually a person's or a company's name.
+
+Profile conformance is not privacy compliance. Run `auditmodel lint-privacy` as well; every fixture
+here is required by test to pass both.
+
+## Known rule-language limitations
+
+The v0.1 rule language checks presence, JSON type and strict scalar equality. It has no regular
+expressions, no numeric comparison, no cross-field comparison, no boolean combination and no
+array-content predicates. Consequences worth stating plainly:
+
+- **`CUSTOMER-LIMIT-001` cannot check the direction or the size of a limit change.** It requires that
+  `/change/before` and `/change/after` both be recorded and leaves the comparison — and any threshold
+  above which a second approver is expected — to the reviewer or to a downstream policy engine. The
+  profile can guarantee the evidence exists; it cannot evaluate it.
+- **No rule can require that a status actually changed.** `CUSTOMER-STATE-001` requires `/change` and
+  the resulting `status`, but it cannot assert that `/change/before/status` differs from
+  `/change/after/status`, because that is a cross-field comparison.
+- **No rule can require that `/relatedResources` contains a customer.** `CUSTOMER-MERGE-001` requires
+  the array to be present and non-empty; array contents are never inspected. The retired record is
+  therefore _also_ required in `/metadata/customer/mergedFromId`, where a scalar check works.
+- **A rule cannot say "either A or B".** There is no disjunction, so where two shapes are both
+  legitimate the profile requires whichever fact both shapes can carry.
+- **Only one condition per rule.** "Required when the override is manual _and_ the account is frozen"
+  is not expressible; such a requirement would have to be split or dropped. It was dropped.
+- **`account.limit.` and `account.status.` are prefixes**, so a producer that emitted
+  `account.limit.view` would find it governed. Reads should be named after what is read
+  (`account.balance.view`), not placed under a mutation sub-family. This is guidance, not something
+  the rule language can enforce.
+- **Outcome and error are left entirely to the core.** The core schema already requires
+  `/event/error` whenever `outcome` is `failure`, and `errorDescriptor` already requires `code`. A
+  profile rule restating that would add nothing, so there is none.
+
+## Cross-profile overlaps
+
+### identity-and-access-management — the boundary that matters most
+
+[identity-and-access-management](../identity-and-access-management/) governs **identities**: who can
+sign in, what they may do, and with what credentials. It selects on the `identity.` prefix and covers
+`identity.user.*`, `identity.role.*`, `identity.permission.*`, `identity.service-account.*` and
+`identity.credential.rotate`.
+
+This profile governs **business parties and business accounts**: who the organization deals with and
+on what terms. The two never select the same event — `identity.` is not a prefix here, and neither
+`customer.` nor `account.` is a prefix there — so no event is ever governed by both, and the
+requirements can never conflict.
+
+| Question                                 | Profile                         | Example event                |
+| ---------------------------------------- | ------------------------------- | ---------------------------- |
+| May this login reach that system?        | identity-and-access-management  | `identity.role.assign`       |
+| Is this party allowed to trade with us?  | customer-and-account-management | `customer.restrict`          |
+| Disable a person's ability to sign in    | identity-and-access-management  | `identity.user.disable`      |
+| Freeze a business account's transactions | customer-and-account-management | `account.freeze`             |
+| Rotate a credential                      | identity-and-access-management  | `identity.credential.rotate` |
+| Close a commercial relationship          | customer-and-account-management | `customer.close`             |
+
+**Do not reuse `identity.*` for business-account lifecycle.** A customer portal login account and the
+settlement account it can operate are different objects with different owners, different lifecycles
+and different reviewers; collapsing them makes "which accounts were frozen?" unanswerable. When a
+single operation does both — offboarding closes the relationship _and_ disables the sign-in — emit two
+events and correlate them with `/request/correlationId`. Each is then governed by exactly one profile
+and both are complete.
+
+Where the two profiles chose the same idea they chose the same shape, so that a reviewer moves between
+them without relearning anything: a `type` category on the record (`/metadata/user/type` there,
+`/metadata/customer/customerType` here), a producer-set boolean discriminator driving a conditional
+rule, and namespaced metadata throughout.
+
+### financial-transaction-management — the other place a limit appears
+
+That profile governs the movement of value: `financial.transfer.*`, `financial.payment.*`,
+`financial.reversal.*`, `financial.settlement.*` and, notably, `financial.limit.*`. This profile
+governs the _account_ whose limit it is, under `account.limit.*`. The two prefixes are disjoint, so
+again no event is governed by both, but the boundary deserves stating because both concern limits:
+
+- **`account.limit.*` is an attribute of the account.** Raising the daily transfer ceiling on
+  `account-ref-781` is an act of account administration performed by an operator. It belongs here.
+- **`financial.limit.*` is a control on the payment flow.** A limit consumed, breached or waived while
+  a transfer is being processed belongs there, with the transaction it constrained.
+
+If in doubt: the event that names an **account** as its resource and changes what that account may do
+from now on is this profile's; the event that names a **transaction** and explains why it was allowed,
+blocked or reversed is the financial profile's.
+
+### document-management
+
+[document-management](../document-management/) may govern the contract or onboarding pack attached to
+a customer. Those are `document.*` events and are not selected here. A customer file and a customer
+record are different resources; keep them as different events.
+
+### Other profiles
+
+`incident-management`, `deployment-and-change-management`, `secrets-and-key-management`,
+`backup-and-recovery`, `message-broker-management` and `api-and-integration-management` all select
+disjoint namespaces (`incident.`, `problem.`, `corrective-action.`, `deployment.`, `change.request.`,
+`configuration.`, `secret.`, `key.`, `certificate.`, `backup.`, `snapshot.`, `restore.`, `recovery.`,
+`broker.`, `api-key.`, `webhook.`, `integration.`). A fraud incident may cause an account freeze and a
+migration may re-limit accounts, but the events stay separate and are joined by
+`/request/correlationId` or `/change/incidentId` rather than by one profile governing another's
+events.
+
+## Not required, and why
+
+- **KYC, sanctions, credit and identity-verification outcomes.** Real and important, but they are
+  regulatory and jurisdictional constructs. [profiles/README.md](../README.md) is explicit that a
+  profile cites no regulation and encodes no jurisdiction. Producers should model these as their own
+  events and put the detail in `metadata` or an extension.
+- **Balances, amounts and currencies.** A balance is business data, not audit interpretation data,
+  and requiring it would push monetary values into every audit event. `CUSTOMER-LIMIT-001` requires
+  before-and-after values only for the limit that changed, because there the pair _is_ the audit fact.
+- **`/authentication` or MFA on restrictive operations.** The IAM profile requires
+  `/authentication/mfa` for privileged role changes because a role change is an access change. A
+  customer freeze is performed by an already-authenticated operator in a back-office console, and the
+  session's factors are a property of the console, not of the operation. It is recorded in the
+  `account-freeze` fixture as good practice and required by no rule.
+- **Trace identifiers.** `/request/traceId` and `/request/spanId` are never required or recommended:
+  a conforming producer may have no tracing at all. `/request/correlationId` is recommended, because
+  onboarding, review and offboarding are genuinely multi-event workflows.
+- **`/request/protocol`.** These operations arrive over consoles, APIs, batch files and back-office
+  terminals. Requiring a protocol would describe the mechanism rather than the operation.
+- **A customer approval event family.** Approval is already modelled by `workflow.approval.*` in
+  [workflow-and-approval.md](../../semantic-conventions/workflow-and-approval.md) and by the core
+  `/approval` object.
+
+## Fixtures
+
+[examples/profiles/customer-and-account-management/](../../examples/profiles/customer-and-account-management/)
+— twelve valid, twelve invalid, three not-applicable.
+
+| Kind              | Count | Guarantee                                                              |
+| ----------------- | ----- | ---------------------------------------------------------------------- |
+| `valid/`          | 12    | core-valid, privacy-clean, conforming with **zero** warnings           |
+| `invalid/`        | 12    | core-valid, privacy-clean, exactly one error at one documented pointer |
+| `not-applicable/` | 3     | core-valid, privacy-clean, governed by no rule (exit 3)                |
+
+Every enforceable rule has at least one invalid fixture. The mapping from fixture to rule and pointer
+is in the [fixture README](../../examples/profiles/customer-and-account-management/README.md) and is
+asserted by [conformance/tests/profile-customer-and-account-management.test.ts](../../conformance/tests/profile-customer-and-account-management.test.ts).
+
+## Open questions
+
+- Should `restrictionScope` be a single string or a list of blocked capabilities? A list is more
+  honest for systems that restrict several capabilities at once, but the rule language cannot inspect
+  array contents, so a required array would be a presence check on an unexaminable value. v0.1 takes
+  the string.
+- Is `deletionScope` the right discriminator for erasure, or should erasure be its own event name
+  (`customer.erase`) distinct from record deletion? There is not yet adoption evidence either way.
+- Should account reopening require the reason the original closure was reversed, separately from the
+  reason for reopening? Two justifications on one event has no precedent in the core model.
+- Is `onBehalfOf` redundant with `/delegation`? For producers that model delegation it is; for the
+  many that record acting-for relationships informally it is the only signal available. The profile
+  accepts the redundancy rather than lose the case.

package/profiles/customer-and-account-management/profile.json

@@ -0,0 +1,237 @@
+{
+  "profileVersion": "0.1",
+  "name": "customer-and-account-management",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "Customer and Account Management Profile",
+  "description": "Additional conformance requirements for material customer and business-account lifecycle audit events: customer record creation, update, merge, restriction, closure and deletion, and account opening, update, status transition, limit change, freeze, restriction and closure. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it. This profile governs business parties and business accounts; identities, authentication and access rights are governed by the identity-and-access-management profile. High-volume read events such as customer.profile.view, customer.search and account.balance.view are deliberately not governed.",
+  "rules": [
+    {
+      "id": "CUSTOMER-CORE-001",
+      "description": "Every governed customer or account operation records the kind of party the record belongs to.",
+      "rationale": "Whether a record describes an individual consumer, a business, an intermediary, an internal test party or a partner is the single fact that decides how an operation on it should be reviewed, and it is not derivable from an opaque identifier. Carrying it on the event rather than expecting a join is deliberate: the customer record the join would need may since have been merged, restricted or deleted, and the operations this profile governs are exactly the ones that do that. The party type is a category, not personal data.",
+      "severity": "error",
+      "events": [
+        "customer.create",
+        "customer.update",
+        "customer.merge",
+        "customer.close",
+        "customer.delete",
+        "customer.restrict",
+        "customer.restore",
+        "account.open",
+        "account.update",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "requiredMetadata": [{ "path": "/customer/customerType", "type": "string" }]
+    },
+    {
+      "id": "CUSTOMER-CORE-002",
+      "description": "A governed customer or account operation should record why it happened, how sensitive the record is, and how it correlates with the wider workflow it belongs to.",
+      "rationale": "Onboarding, periodic review and offboarding are multi-step workflows whose steps are emitted by different services, so a correlation identifier is what turns a scattering of events back into one case. These are recommended rather than required because a conforming producer may have no correlation mechanism at all, because a classification scheme is an organization's decision rather than this profile's, and because a missing justification on a routine update should prompt a question rather than fail a build. Where a justification is genuinely load-bearing, a separate rule requires it.",
+      "severity": "warning",
+      "events": [
+        "customer.create",
+        "customer.update",
+        "customer.merge",
+        "customer.close",
+        "customer.delete",
+        "customer.restrict",
+        "customer.restore",
+        "account.open",
+        "account.update",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "recommendedPaths": ["/reason", "/request/correlationId", "/resource/classification"]
+    },
+    {
+      "id": "CUSTOMER-ACCOUNT-001",
+      "description": "An account operation records the kind of account and the customer the account belongs to.",
+      "rationale": "An account event that does not name its owning customer cannot be joined to the party it affects, so a reviewer asking which parties were frozen last quarter has to reconstruct ownership from a system whose current state may no longer match what was true at the time. The account kind matters for the same reason the party type does: freezing a dormant internal settlement account and freezing a customer's only operating account are different acts that otherwise look identical in the trail.",
+      "severity": "error",
+      "events": [
+        "account.open",
+        "account.update",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "requiredPaths": ["/resource/ownerId"],
+      "requiredMetadata": [{ "path": "/customer/accountType", "type": "string" }]
+    },
+    {
+      "id": "CUSTOMER-CONTROL-001",
+      "description": "An operation that restricts, closes, restores, merges, deletes or re-limits a customer or an account records the authorization decision that permitted it and why it was performed.",
+      "rationale": "These are the operations that take a customer's ability to transact away or give it back, and they are the ones a complaint, a dispute or a supervisory question later turns on. Without a recorded decision nothing distinguishes an action policy allowed from one that bypassed policy; without a stated justification the trail cannot say whether a freeze was a fraud control, a billing dispute or a mistake, and the person who knew will not be reachable when the question is asked. Approval is recommended rather than required because many organizations legitimately let a single trained operator freeze an account on suspicion; a rule that forbade it would be switched off rather than met.",
+      "severity": "error",
+      "events": [
+        "customer.merge",
+        "customer.close",
+        "customer.delete",
+        "customer.restrict",
+        "customer.restore",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "requiredPaths": ["/authorization", "/reason"],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "CUSTOMER-UPDATE-001",
+      "description": "An update to a customer record or an account records what changed.",
+      "rationale": "An update event without a change context records only that something was altered, which is the least useful thing an audit trail can say about a mutation. The profile requires the change object and nothing about its shape: the core already accepts changed field names, sanitized state, hashes or references, and a customer record is exactly the kind of data where recording field names instead of values is the right answer.",
+      "severity": "error",
+      "events": ["customer.update", "account.update"],
+      "requiredPaths": ["/change"],
+      "recommendedPaths": ["/change/changedFields"]
+    },
+    {
+      "id": "CUSTOMER-STATE-001",
+      "description": "A status transition on a customer or an account records the resulting status and the transition itself.",
+      "rationale": "A closure, freeze, restriction or reinstatement is meaningful only as a move between two states. An event that names the action but not the resulting status forces every consumer to model the producer's state machine correctly in order to know where the record ended up, and consumers get that wrong. Recording the resulting status makes the trail replayable: the state after any transition can be read directly instead of inferred from the event name.",
+      "severity": "error",
+      "events": [
+        "customer.close",
+        "customer.restrict",
+        "customer.restore",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.status."],
+      "requiredPaths": ["/change"],
+      "requiredMetadata": [{ "path": "/customer/status", "type": "string" }]
+    },
+    {
+      "id": "CUSTOMER-RESTRICT-001",
+      "description": "A restriction or freeze records what the restriction actually prevents.",
+      "rationale": "Restriction is not one control. Blocking outgoing payments, blocking new orders, blocking sign-in and blocking the whole relationship have very different consequences for the customer, and they are routinely emitted under the same event name. Without the scope, nobody can later tell whether a restriction was proportionate, nor lift it safely, and a customer complaint about being cut off cannot be answered from the trail at all. The review that triggered the restriction is recommended rather than required, because a restriction may equally be an immediate operational decision with no review behind it.",
+      "severity": "error",
+      "events": ["customer.restrict", "account.restrict", "account.freeze"],
+      "requiredMetadata": [{ "path": "/customer/restrictionScope", "type": "string" }],
+      "recommendedPaths": ["/approval", "/metadata/customer/reviewId"]
+    },
+    {
+      "id": "CUSTOMER-LIMIT-001",
+      "description": "A limit change records which limit changed and both the prior and the resulting value.",
+      "rationale": "A limit change is only reviewable as a pair of numbers: raising a transfer ceiling from a small figure to a very large one and lowering it are the same event name with opposite risk. Recording only the new value hides the direction and the magnitude of the change. The profile requires which limit was touched because an account carries several, and it requires both states rather than a computed delta because the rule language compares nothing: the engine can check that both values were recorded and must leave the comparison, and any threshold, to the reviewer.",
+      "severity": "error",
+      "eventPrefixes": ["account.limit."],
+      "requiredPaths": ["/change/before", "/change/after"],
+      "requiredMetadata": [{ "path": "/customer/limitType", "type": "string" }]
+    },
+    {
+      "id": "CUSTOMER-MERGE-001",
+      "description": "A customer merge names the record that was retired and the records the merge related.",
+      "rationale": "A merge collapses two parties into one and is the hardest customer operation to undo or explain. Every identifier that pointed at the retired record becomes unresolvable at the moment of the merge, so an event that does not name that record breaks the trail of everything that referenced it, and the surviving record appears to acquire history from nowhere. Requiring the related resources as well keeps both sides of the merge on the event, so that a reviewer never has to guess which direction it ran.",
+      "severity": "error",
+      "events": ["customer.merge"],
+      "requiredPaths": ["/relatedResources"],
+      "requiredMetadata": [{ "path": "/customer/mergedFromId", "type": "string" }]
+    },
+    {
+      "id": "CUSTOMER-DELETE-001",
+      "description": "Deleting a customer record records how far the deletion reached.",
+      "rationale": "Deletion is the operation an audit trail is least able to reconstruct afterwards, because the evidence is precisely what was removed. Erasing a party's personal data while retaining the transactional record is a different act from removing the record entirely, and the two are habitually emitted under one name. Recording the scope is what lets a later reader answer what still exists, and it is the only honest way to distinguish an erasure that was performed from one that was claimed. The privacy context and an approval are recommended rather than required because neither is universal.",
+      "severity": "error",
+      "events": ["customer.delete"],
+      "requiredMetadata": [{ "path": "/customer/deletionScope", "type": "string" }],
+      "recommendedPaths": ["/approval", "/privacy"]
+    },
+    {
+      "id": "CUSTOMER-APPROVAL-001",
+      "description": "When the producer declares that an operation required approval, the state of that approval is recorded.",
+      "rationale": "This profile does not decide which customer or account operations need a second person, because that varies by organization, product and jurisdiction and no vendor-neutral answer exists. It enforces the consequence of the producer's own declaration instead: an operation the system itself said required approval, carried out with no approval state on the event, is either an unapproved change or an unrecorded one, and the trail cannot tell which. The rule requires the status rather than the approval object so that the finding points at the fact that is missing rather than at its container.",
+      "severity": "error",
+      "events": [
+        "customer.create",
+        "customer.update",
+        "customer.merge",
+        "customer.close",
+        "customer.delete",
+        "customer.restrict",
+        "customer.restore",
+        "account.open",
+        "account.update",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "when": { "path": "/metadata/customer/approvalRequired", "equals": true },
+      "requiredPaths": ["/approval/status"]
+    },
+    {
+      "id": "CUSTOMER-SUBJECT-001",
+      "description": "An operation the producer declares was carried out on behalf of another party names that party.",
+      "rationale": "Customer and account operations are frequently performed by an agent, a branch operator or a support engineer for someone else, and in that case the actor is not the party the operation was about. The core already requires a subject when a delegation object is present, but a great many systems record acting-for relationships without modelling delegation at all, and then the trail attributes a closure to the operator who typed it. This rule fires only on the producer's own declaration, so the profile does not have to decide what acting on behalf of means in a given deployment.",
+      "severity": "error",
+      "events": [
+        "customer.create",
+        "customer.update",
+        "customer.merge",
+        "customer.close",
+        "customer.delete",
+        "customer.restrict",
+        "customer.restore",
+        "account.open",
+        "account.update",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "when": { "path": "/metadata/customer/onBehalfOf", "equals": true },
+      "requiredPaths": ["/subject"]
+    },
+    {
+      "id": "CUSTOMER-OVERRIDE-001",
+      "description": "An operation the producer declares was a manual override records the authorization decision it was recorded against and why the override was made.",
+      "rationale": "A manual override is a person setting aside what the system would otherwise have done, and it is the single most reviewable act in customer administration: overrides are where fraud, favouritism and honest emergency handling all look alike. Without a justification the trail cannot separate them, and without the recorded decision it cannot even show what was overridden. The rule extends this to ordinary updates and openings, which no other rule in this profile requires a justification for, because an overridden routine change is not a routine change.",
+      "severity": "error",
+      "events": [
+        "customer.create",
+        "customer.update",
+        "customer.merge",
+        "customer.close",
+        "customer.delete",
+        "customer.restrict",
+        "customer.restore",
+        "account.open",
+        "account.update",
+        "account.close",
+        "account.reopen",
+        "account.freeze",
+        "account.unfreeze",
+        "account.restrict"
+      ],
+      "eventPrefixes": ["account.limit.", "account.status."],
+      "when": { "path": "/metadata/customer/manualOverride", "equals": true },
+      "requiredPaths": ["/authorization", "/reason"]
+    }
+  ]
+}