@openauditmodel/cli 0.2.1 → 0.4.0

package/profiles/customer-and-account-management/0.1/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"]
+    }
+  ]
+}

package/profiles/deployment-and-change-management/0.1/profile.json

@@ -0,0 +1,298 @@
+{
+  "profileVersion": "0.1",
+  "name": "deployment-and-change-management",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "Deployment and Change Management Profile",
+  "description": "Additional conformance requirements for audit events that describe material change to a running system: releases, deployments, promotions, rollbacks, cancellations, infrastructure application, configuration and secret changes, and change requests. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it. The profile supports fully automated continuous delivery as well as human-gated release: it never decides which change needs approval, it requires the producer to record whether one was required. Routine pipeline telemetry such as polling, build log output and secret reads is deliberately not governed.",
+  "rules": [
+    {
+      "id": "DEPLOY-CORE-001",
+      "description": "Every governed change identifies the deployment, release or change record it belongs to, and the environment the change was applied to.",
+      "rationale": "One change produces events from many stages and often from several different services, and nothing else in an event ties those stages together: `id` is unique per event and `resource` legitimately differs between the release, the approval and the target. Without a shared identifier a reviewer cannot say which approval belongs to which deployment, or which rollback undid which release. The environment is recorded separately from `application.environment` because `application` describes the system that performed the change, not the system that received it: a delivery platform runs in one environment and deploys into others, and conflating the two makes every environment-scoped review wrong.",
+      "severity": "error",
+      "events": [
+        "change.request.approve",
+        "change.request.cancel",
+        "change.request.close",
+        "change.request.create",
+        "change.request.reject",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update",
+        "configuration.secret.rotate",
+        "configuration.setting.create",
+        "configuration.setting.delete",
+        "configuration.setting.update"
+      ],
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "requiredMetadata": [
+        {
+          "path": "/deployment/id",
+          "type": "string"
+        },
+        {
+          "path": "/deployment/environment",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DEPLOY-CORE-002",
+      "description": "Every governed change states whether policy required it to be approved.",
+      "rationale": "This profile deliberately does not decide which changes need a human approval. Continuous delivery, human-gated release, scheduled maintenance and emergency repair are all legitimate delivery models, and a profile that demanded an approval on every production deployment would describe one of them and be switched off by everyone using another. The producer declares the policy in this flag and DEPLOY-APPROVAL-002 enforces the consequence. The flag is required rather than inferred because a conditional rule contributes nothing when its path is absent: silence would read as \"no approval was required\" when it may mean \"nobody recorded whether one was\", and those are the two answers a change review most needs to tell apart.",
+      "severity": "error",
+      "events": [
+        "change.request.approve",
+        "change.request.cancel",
+        "change.request.close",
+        "change.request.create",
+        "change.request.reject",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update",
+        "configuration.secret.rotate",
+        "configuration.setting.create",
+        "configuration.setting.delete",
+        "configuration.setting.update"
+      ],
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "requiredMetadata": [
+        {
+          "path": "/deployment/approvalRequired",
+          "type": "boolean"
+        }
+      ]
+    },
+    {
+      "id": "DEPLOY-CORE-003",
+      "description": "A governed change should record why it was made, the pipeline that produced it, and the identifier that correlates it with the rest of the operation.",
+      "rationale": "These are the fields a reviewer reaches for first and a producer omits most often. They are recommended rather than required because a routine automated deployment often has no justification beyond the change having been merged, because not every change comes from a pipeline, and because a configuration change made by hand from a console has no correlation identifier to carry. A missing one should prompt a question rather than fail a build.",
+      "severity": "warning",
+      "events": [
+        "change.request.approve",
+        "change.request.cancel",
+        "change.request.close",
+        "change.request.create",
+        "change.request.reject",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update",
+        "configuration.secret.rotate",
+        "configuration.setting.create",
+        "configuration.setting.delete",
+        "configuration.setting.update"
+      ],
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "recommendedPaths": ["/reason", "/request/correlationId", "/metadata/deployment/pipelineId"]
+    },
+    {
+      "id": "DEPLOY-RELEASE-001",
+      "description": "A release or infrastructure event names the version it concerns.",
+      "rationale": "A deployment trail that does not name a version records that something was released without recording what. Every later question depends on it: which build introduced a regression, whether an environment is running the artifact that was approved, and whether a rollback reached the version it aimed at. The profile requires an identifier and asserts nothing about its form, because semantic versions, tags, ordinal build numbers and content digests are all in legitimate use and no scheme is universal. What was changed by the release belongs in `relatedResources`, which is recommended rather than required so that a single-target deployment is not forced to duplicate its own `resource`.",
+      "severity": "error",
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "requiredMetadata": [
+        {
+          "path": "/deployment/version",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/relatedResources", "/change/deploymentId"]
+    },
+    {
+      "id": "DEPLOY-RELEASE-002",
+      "description": "An event that changes what is running records the version it replaced.",
+      "rationale": "An incident review starts from what was running before, and that answer is only cheaply available at the moment of the change: reconstructing it later means trusting that no other event was lost from the same environment. Recording both versions on the event that moved between them makes the transition self-describing, lets a rollback be matched to the deployment it reverted, and turns \"which version was live at this time?\" into a lookup rather than a replay. A first deployment into an empty environment has a real answer too, and producers should record it explicitly rather than omit the field.",
+      "severity": "error",
+      "events": [
+        "deployment.release.deploy",
+        "deployment.release.promote",
+        "deployment.release.rollback",
+        "deployment.infrastructure.apply"
+      ],
+      "requiredMetadata": [
+        {
+          "path": "/deployment/previousVersion",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DEPLOY-REVERT-001",
+      "description": "Reverting or stopping a change in flight records the decision that permitted it and why the change was undone.",
+      "rationale": "A rollback or a cancellation discards work that the normal path had already accepted, and it is usually performed under time pressure by whoever was available rather than by whoever owns the change. Without a recorded authorization decision nothing distinguishes a considered revert from one person overriding another team, and without a justification the trail cannot say whether the change was withdrawn because it was wrong, because it was risky, or because something unrelated was failing at the time. Approval is recommended rather than required here precisely because a revert is often the correct emergency action and the approval is retrospective.",
+      "severity": "error",
+      "events": ["deployment.release.rollback", "deployment.release.cancel"],
+      "requiredPaths": ["/authorization", "/reason"],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "DEPLOY-CONFIG-001",
+      "description": "A configuration, feature, policy, retention or secret change records the decision that permitted it and which settings changed.",
+      "rationale": "Configuration is where controls are switched off, and a configuration change usually leaves no trace in business data at all, so the event is the only evidence that it happened. The authorization decision is what separates a change policy allowed from one that bypassed policy. The names of the settings that changed are required rather than their values, because the field list is the one representation every configuration system can produce and the one that never discloses a secret: a rotation records that the secret field changed and nothing about the secret. Producers may add sanitized before and after values where they are safe; this profile does not require them.",
+      "severity": "error",
+      "events": [
+        "configuration.setting.create",
+        "configuration.setting.update",
+        "configuration.setting.delete",
+        "configuration.secret.rotate",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update"
+      ],
+      "requiredPaths": ["/authorization", "/change/changedFields"]
+    },
+    {
+      "id": "DEPLOY-APPROVAL-001",
+      "description": "An event that is itself an approval decision records the resulting approval status.",
+      "rationale": "These events exist to record a human decision, so an approval event without an approval state records that a decision was reached without recording which one. The status is required because it is the fact the event is about; the workflow and the approving principals are recommended because a two-person review conducted in a ticket is a real approval process and has no workflow engine behind it. The profile does not require the status to match the event name: an approval attempt can fail, and an event that had to lie about its own outcome to conform would be worse evidence than one that did not conform.",
+      "severity": "error",
+      "events": ["deployment.release.approve", "change.request.approve", "change.request.reject"],
+      "requiredPaths": ["/approval/status"],
+      "recommendedPaths": ["/approval/workflowId", "/approval/approvers"]
+    },
+    {
+      "id": "DEPLOY-APPROVAL-002",
+      "description": "When the producer has declared that policy required approval, the event that carried the change out records the approval state it was carried out under.",
+      "rationale": "This is the rule the approvalRequired flag exists for, and it is deliberately about the executing event rather than the approving one: the question a review asks is not whether an approval exists somewhere but whether the change that actually reached the environment was covered by it. Requiring the status rather than an approved status is intentional. A change executed while approval was still pending is a control bypass, and the specification requires producers to record that honestly rather than suppress it; a rule that only accepted `approved` would make the most important event in the trail unrepresentable and would be met by omitting the flag instead.",
+      "severity": "error",
+      "events": [
+        "deployment.release.deploy",
+        "deployment.release.promote",
+        "deployment.release.rollback",
+        "deployment.release.cancel",
+        "deployment.infrastructure.apply",
+        "configuration.setting.create",
+        "configuration.setting.update",
+        "configuration.setting.delete",
+        "configuration.secret.rotate",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update"
+      ],
+      "when": {
+        "path": "/metadata/deployment/approvalRequired",
+        "equals": true
+      },
+      "requiredPaths": ["/approval/status"],
+      "recommendedPaths": ["/change/ticketId"]
+    },
+    {
+      "id": "DEPLOY-EMERGENCY-001",
+      "description": "A change the producer has flagged as bypassing the normal change path is justified.",
+      "rationale": "An emergency change, a break-glass repair and an overridden pipeline gate are the same fact from an audit point of view: the controls that normally govern change were not applied, by a decision someone made at the time. That decision is the thing a post-incident review needs and the thing nobody writes down afterwards, because the people involved were busy. The profile does not define when a change may bypass the path, and it does not require the bypass to have been approved; it requires the reason to exist while the answer is still known. The incident the change responded to and any retrospective approval are recommended for the same reason.",
+      "severity": "error",
+      "events": [
+        "change.request.approve",
+        "change.request.cancel",
+        "change.request.close",
+        "change.request.create",
+        "change.request.reject",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update",
+        "configuration.secret.rotate",
+        "configuration.setting.create",
+        "configuration.setting.delete",
+        "configuration.setting.update"
+      ],
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "when": {
+        "path": "/metadata/deployment/emergency",
+        "equals": true
+      },
+      "requiredPaths": ["/reason"],
+      "recommendedPaths": ["/approval", "/change/incidentId"]
+    },
+    {
+      "id": "DEPLOY-FAILURE-001",
+      "description": "A change that failed records the state the target was left in.",
+      "rationale": "A failed change is not self-describing. `outcome: failure` says the operation did not complete; it does not say whether the target was left untouched, left half-updated, or automatically reverted, and those three answers call for completely different responses. The state is the one fact only the producer can supply and the one nobody can reconstruct from the outside once the pipeline has moved on. The profile requires the answer to be recorded and does not constrain the vocabulary used to express it, because what counts as partially applied depends on what was being changed. The core model already requires a sanitized error code on a failure; a human readable message is recommended in addition.",
+      "severity": "error",
+      "events": [
+        "change.request.approve",
+        "change.request.cancel",
+        "change.request.close",
+        "change.request.create",
+        "change.request.reject",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update",
+        "configuration.secret.rotate",
+        "configuration.setting.create",
+        "configuration.setting.delete",
+        "configuration.setting.update"
+      ],
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "when": {
+        "path": "/event/outcome",
+        "equals": "failure"
+      },
+      "requiredMetadata": [
+        {
+          "path": "/deployment/resultingState",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/event/error/message"]
+    },
+    {
+      "id": "DEPLOY-FAILURE-002",
+      "description": "A change that succeeded for some targets and failed for others records the state the targets were left in.",
+      "rationale": "A deployment across many instances is the clearest case in the model for `outcome: partial`, and it is also the case where the resulting state matters most: a partially applied change means two versions are serving at once, which is a configuration nobody designed and nobody tested. This rule is a duplicate of DEPLOY-FAILURE-001 with a different condition because the v0.1 rule language allows exactly one equality condition per rule and has no disjunction. Stating the requirement twice is preferred to stating it once and quietly leaving the partial case ungoverned.",
+      "severity": "error",
+      "events": [
+        "change.request.approve",
+        "change.request.cancel",
+        "change.request.close",
+        "change.request.create",
+        "change.request.reject",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update",
+        "configuration.secret.rotate",
+        "configuration.setting.create",
+        "configuration.setting.delete",
+        "configuration.setting.update"
+      ],
+      "eventPrefixes": ["deployment.release.", "deployment.infrastructure."],
+      "when": {
+        "path": "/event/outcome",
+        "equals": "partial"
+      },
+      "requiredMetadata": [
+        {
+          "path": "/deployment/resultingState",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DEPLOY-AUTOMATION-001",
+      "description": "When automation carried the change out, the principal it acted for should be named in `subject` and the transfer of authority in `delegation`.",
+      "rationale": "Automation performs most material change, so the actor on a deployment event is usually a service and the person who decided the change should happen is not in the event at all. The core model can express that in two ways, and this profile picks one: the human author is the `subject`, the service is the `actor`, and `delegation` says how authority moved between them. Recording the author in metadata would work for one product and be unreadable across two. It is a recommendation rather than a requirement because unattended automation such as drift correction or a scheduled reconciliation genuinely has no human author, and the resulting warning is the correct signal for a reviewer rather than a defect.",
+      "severity": "warning",
+      "events": [
+        "deployment.release.deploy",
+        "deployment.release.promote",
+        "deployment.release.rollback",
+        "deployment.release.cancel",
+        "deployment.infrastructure.apply",
+        "configuration.setting.create",
+        "configuration.setting.update",
+        "configuration.setting.delete",
+        "configuration.secret.rotate",
+        "configuration.feature.toggle",
+        "configuration.policy.update",
+        "configuration.retention.update"
+      ],
+      "when": {
+        "path": "/actor/type",
+        "equals": "service"
+      },
+      "recommendedPaths": ["/subject", "/delegation"]
+    }
+  ]
+}