@openauditmodel/cli 0.3.0 → 0.4.0

package/profiles/document-management/0.1/profile.json

@@ -0,0 +1,170 @@
+{
+  "profileVersion": "0.1",
+  "name": "document-management",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "Document Management Profile",
+  "description": "Additional conformance requirements for document management audit events: creation, deletion, download, versioning, sharing, access policy, retention and legal hold. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it. High-volume read events such as document.file.view are deliberately not governed.",
+  "rules": [
+    {
+      "id": "DOC-CORE-001",
+      "description": "Every governed document operation records the authorization decision that permitted it and the classification of the document it acted on.",
+      "rationale": "A document operation without a recorded decision cannot be reviewed: nothing distinguishes an action policy allowed from one that bypassed policy. Without a classification, a reviewer cannot tell whether the operation touched public material or the most sensitive record the organization holds, and every triage decision downstream depends on that difference.",
+      "severity": "error",
+      "events": ["document.file.upload", "document.file.delete", "document.file.download"],
+      "eventPrefixes": [
+        "document.share.",
+        "document.permission.",
+        "document.version.",
+        "document.retention.",
+        "document.legal-hold."
+      ],
+      "requiredPaths": ["/authorization", "/resource/classification"]
+    },
+    {
+      "id": "DOC-CORE-002",
+      "description": "A governed document operation should record why it happened, where the document lives, and how it correlates with the wider 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 conforming system may legitimately have no container hierarchy, and because a missing justification should prompt a question rather than fail a build.",
+      "severity": "warning",
+      "events": ["document.file.upload", "document.file.delete", "document.file.download"],
+      "eventPrefixes": [
+        "document.share.",
+        "document.permission.",
+        "document.version.",
+        "document.retention.",
+        "document.legal-hold."
+      ],
+      "recommendedPaths": ["/reason", "/resource/parentId", "/request/correlationId"]
+    },
+    {
+      "id": "DOC-SHARE-001",
+      "description": "A share event records the kind of recipient the access was granted to or withdrawn from.",
+      "rationale": "Whether a document went to a colleague, a partner or an anonymous link is the single fact that determines the risk of the operation, and it cannot be reconstructed later from an identifier alone.",
+      "severity": "error",
+      "eventPrefixes": ["document.share."],
+      "requiredMetadata": [
+        {
+          "path": "/share/recipientType",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DOC-SHARE-002",
+      "description": "Creating a share records the permission granted, and should record when the access ends.",
+      "rationale": "A share that does not say what the recipient may do records that something was shared without recording what was given away. An expiry is recommended here and required for external recipients, because indefinite internal access is often a deliberate and reasonable choice.",
+      "severity": "error",
+      "events": ["document.share.create"],
+      "requiredMetadata": [
+        {
+          "path": "/share/permission",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/metadata/share/expiresAt"]
+    },
+    {
+      "id": "DOC-SHARE-003",
+      "description": "A share to an external recipient is time-bounded and justified.",
+      "rationale": "An external share is a disclosure outside the organization's control. Without an expiry it is indefinite, and without a stated reason there is no record of who decided the disclosure was acceptable. This rule fires only when the producer has declared the recipient external, so the profile does not have to guess what external means for a given deployment.",
+      "severity": "error",
+      "events": ["document.share.create"],
+      "when": {
+        "path": "/metadata/share/recipientType",
+        "equals": "external"
+      },
+      "requiredPaths": ["/reason"],
+      "requiredMetadata": [
+        {
+          "path": "/share/expiresAt",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DOC-PERM-001",
+      "description": "A document permission change names the principal whose access changed and the permission involved.",
+      "rationale": "An access-policy change that does not say whose access changed is not reviewable at all. The principal is recorded in namespaced metadata rather than in `/subject`, because [actor-model.md](../../specification/actor-model.md) §5 defines `subject` as the principal *on whose behalf* the actor acted, and forbids its use as a generic target. A grantee or assignee is neither. This follows the identity profile, which records a role in `/metadata/role/id` for the same reason.",
+      "severity": "error",
+      "eventPrefixes": ["document.permission."],
+      "requiredMetadata": [
+        {
+          "path": "/permission/id",
+          "type": "string"
+        },
+        {
+          "path": "/permission/granteeId",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/reason"]
+    },
+    {
+      "id": "DOC-VERSION-001",
+      "description": "A version event identifies the version it produced or restored.",
+      "rationale": "Version history is the record of what a document said at a point in time. An event that does not name the version cannot be tied to the content it describes.",
+      "severity": "error",
+      "eventPrefixes": ["document.version."],
+      "requiredMetadata": [
+        {
+          "path": "/version/id",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DOC-VERSION-002",
+      "description": "A rollback records the version it replaced and why the current content was discarded.",
+      "rationale": "A rollback destroys the prevailing content. Without the replaced version the trail cannot say what was undone, and without a reason it cannot say whether the change was a correction or a reversal of someone else's work.",
+      "severity": "error",
+      "events": ["document.version.rollback"],
+      "requiredPaths": ["/reason"],
+      "requiredMetadata": [
+        {
+          "path": "/version/previousId",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "DOC-DELETE-001",
+      "description": "Deleting a document is justified, and should be approved.",
+      "rationale": "Deletion is the operation an audit trail is least able to reconstruct after the fact, because the evidence is what was removed. Approval is recommended rather than required: many systems legitimately allow an owner to delete their own draft, and a rule that forbade it would be ignored rather than followed.",
+      "severity": "error",
+      "events": ["document.file.delete"],
+      "requiredPaths": ["/reason"],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "DOC-RETENTION-001",
+      "description": "A retention change records the resulting retention class, the transition and why it was made.",
+      "rationale": "Retention determines how long the evidence exists at all, so a change to it is a change to the audit trail's own reach. The profile requires the state and the transition to be recorded; it does not say what any retention class must mean, or how long anything must be kept, because those are organization and jurisdiction decisions this specification does not make.",
+      "severity": "error",
+      "eventPrefixes": ["document.retention."],
+      "requiredPaths": ["/change", "/reason"],
+      "requiredMetadata": [
+        {
+          "path": "/retention/class",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "DOC-HOLD-001",
+      "description": "A legal hold event records whether the hold is in force and why it changed.",
+      "rationale": "A hold suspends normal retention, so an event that does not state the resulting condition leaves the document's disposition ambiguous. The profile records the state and the justification only; it asserts nothing about any jurisdiction's obligations, and conformance with this rule is not compliance with any legal duty.",
+      "severity": "error",
+      "eventPrefixes": ["document.legal-hold."],
+      "requiredPaths": ["/reason"],
+      "requiredMetadata": [
+        {
+          "path": "/legalHold/active",
+          "type": "boolean"
+        }
+      ],
+      "recommendedPaths": ["/approval"]
+    }
+  ]
+}

package/profiles/financial-transaction-management/0.1/profile.json

@@ -0,0 +1,247 @@
+{
+  "profileVersion": "0.1",
+  "name": "financial-transaction-management",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "Financial Transaction Management Profile",
+  "description": "Additional conformance requirements for audit events that record material financial operations: transfers, payments, withdrawals, deposits, refunds, reversals, payouts, settlements, chargebacks, reconciliation adjustments and transaction limit changes. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it. Non-mutating financial reads such as balance enquiries, price quotes and routine reporting are deliberately not governed.",
+  "rules": [
+    {
+      "id": "FIN-CORE-001",
+      "description": "Every governed financial operation records the authorization decision that permitted it.",
+      "rationale": "Money movement is the operation an attacker and a mistaken operator both aim for, and after the fact the two look identical. Without a recorded decision nothing separates a transfer that policy permitted from one that bypassed policy entirely, and a reviewer is left inferring the control state of the system from the fact that the transaction completed. The profile records the decision; it does not evaluate it.",
+      "severity": "error",
+      "events": ["financial.limit.create", "financial.limit.delete", "financial.limit.update"],
+      "eventPrefixes": [
+        "financial.transfer.",
+        "financial.payment.",
+        "financial.withdrawal.",
+        "financial.deposit.",
+        "financial.refund.",
+        "financial.reversal.",
+        "financial.payout.",
+        "financial.settlement.",
+        "financial.chargeback.",
+        "financial.reconciliation."
+      ],
+      "requiredPaths": ["/authorization"]
+    },
+    {
+      "id": "FIN-CORE-002",
+      "description": "A governed financial operation should record why it happened, how the actor was authenticated, and the other financial resources the same operation touched.",
+      "rationale": "These are the three fields a financial reviewer reaches for first and a producer omits most often. They are recommended rather than required because each has a legitimate absence: a scheduled settlement has no per-event business justification, an internal batch process has no interactive authentication context, and a single-sided deposit has no counterparty resource to name. A missing one should prompt a question rather than fail a pipeline.",
+      "severity": "warning",
+      "events": ["financial.limit.create", "financial.limit.delete", "financial.limit.update"],
+      "eventPrefixes": [
+        "financial.transfer.",
+        "financial.payment.",
+        "financial.withdrawal.",
+        "financial.deposit.",
+        "financial.refund.",
+        "financial.reversal.",
+        "financial.payout.",
+        "financial.settlement.",
+        "financial.chargeback.",
+        "financial.reconciliation."
+      ],
+      "recommendedPaths": ["/reason", "/authentication", "/relatedResources"]
+    },
+    {
+      "id": "FIN-TXN-001",
+      "description": "A monetary movement records the transaction it belongs to, the identifier that correlates the whole transaction lifecycle, and the amount and currency that moved.",
+      "rationale": "A financial transaction is almost never one event. An authorization, a capture, a settlement, a refund and a reversal are separate operations against the same money, often minutes or months apart and often produced by different services. Without a transaction reference the events cannot be assembled into a transaction, and without a correlation identifier the transaction cannot be assembled into a case. Amount and currency are what make the trail answerable at all: an event that records that value moved without recording how much and in what unit cannot be reconciled against any ledger, and a bare number without its currency is not an amount.",
+      "severity": "error",
+      "eventPrefixes": [
+        "financial.transfer.",
+        "financial.payment.",
+        "financial.withdrawal.",
+        "financial.deposit.",
+        "financial.refund.",
+        "financial.reversal.",
+        "financial.payout.",
+        "financial.settlement.",
+        "financial.chargeback."
+      ],
+      "requiredPaths": ["/request/correlationId"],
+      "requiredMetadata": [
+        {
+          "path": "/financial/transactionId",
+          "type": "string"
+        },
+        {
+          "path": "/financial/amount",
+          "type": "number"
+        },
+        {
+          "path": "/financial/currency",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "FIN-TXN-002",
+      "description": "A monetary movement records which way value moved and the state the transaction was left in.",
+      "rationale": "The same amount against the same account is a credit or a debit, and the difference is the whole meaning of the event. Direction cannot be reconstructed from the event name because one deployment models a refund as an outbound payment and another as a negative capture. Business status is equally irreplaceable: `event.outcome` says whether the operation the application attempted succeeded, which is not the same question as whether the money has actually moved. A capture can succeed while the transaction remains pending settlement, and a reviewer who conflates the two will report money as final that a counterparty can still recall.",
+      "severity": "error",
+      "eventPrefixes": [
+        "financial.transfer.",
+        "financial.payment.",
+        "financial.withdrawal.",
+        "financial.deposit.",
+        "financial.refund.",
+        "financial.reversal.",
+        "financial.payout.",
+        "financial.settlement.",
+        "financial.chargeback."
+      ],
+      "requiredMetadata": [
+        {
+          "path": "/financial/direction",
+          "type": "string"
+        },
+        {
+          "path": "/financial/status",
+          "type": "string"
+        }
+      ]
+    },
+    {
+      "id": "FIN-LINK-001",
+      "description": "A transfer or a settlement names the other financial resources it moved value between.",
+      "rationale": "A transfer and a settlement are two-sided by definition. The core model gives one resource the primary position, so an event that stops there records exactly half the operation: the money left somewhere and the trail does not say where it went. `relatedResources` is the core field for this and needs no new vocabulary, and a counterparty outside the producer's control can still be named by an opaque reference. This is a strengthening of the general `FIN-CORE-002` recommendation for the two families where a single-sided record is not merely thin but wrong.",
+      "severity": "error",
+      "eventPrefixes": ["financial.transfer.", "financial.settlement."],
+      "requiredPaths": ["/relatedResources"]
+    },
+    {
+      "id": "FIN-REASON-001",
+      "description": "An operation that refuses, withdraws or unwinds value records why.",
+      "rationale": "A completed payment explains itself; a rejected, cancelled, refunded or reversed one does not. These are the operations where the customer disputes the outcome, where the loss is booked, and where the difference between a policy decision, an operational error and a deliberate write-off decides who is accountable. That difference exists only in the justification, and it is knowable only at the moment of the decision. A stated reason also separates a refund issued because goods were returned from one issued to move money to a chosen destination, which is the shape financial abuse takes when it is committed from inside.",
+      "severity": "error",
+      "events": [
+        "financial.payment.reject",
+        "financial.payment.cancel",
+        "financial.transfer.cancel",
+        "financial.payout.cancel",
+        "financial.settlement.cancel",
+        "financial.withdrawal.reject",
+        "financial.refund.create"
+      ],
+      "eventPrefixes": ["financial.reversal.", "financial.chargeback."],
+      "requiredPaths": ["/reason"]
+    },
+    {
+      "id": "FIN-REVERSAL-001",
+      "description": "A reversal or a chargeback names the transaction it acts against.",
+      "rationale": "A reversal has no independent existence: it is defined entirely by the movement it undoes, and an event that does not name that movement records value appearing from nowhere. Matching a reversal to its original by amount and timing is guesswork that fails precisely where it matters, on the accounts with many similar transactions. The same holds for a chargeback, which is raised by a counterparty against a specific earlier payment and whose whole review turns on which one.",
+      "severity": "error",
+      "eventPrefixes": ["financial.reversal.", "financial.chargeback."],
+      "requiredMetadata": [
+        {
+          "path": "/financial/originalTransactionId",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "FIN-APPROVAL-001",
+      "description": "When the producer declares that an operation required approval, the event records the approval decision.",
+      "rationale": "Approval thresholds are a local policy decision that this profile deliberately does not make. A marketplace pays out thousands of small balances an hour with no human involvement and is right to; a treasury team moves one amount a week under dual control and is right to. What the profile can require is consistency: once a producer has declared that this operation required approval, an event that does not carry the resulting decision has recorded the control as applying without recording whether it was satisfied, which is worse than not claiming the control at all. The status is required rather than the object alone because an approval record naming only a workflow does not say whether anyone approved anything.",
+      "severity": "error",
+      "events": ["financial.limit.create", "financial.limit.delete", "financial.limit.update"],
+      "eventPrefixes": [
+        "financial.transfer.",
+        "financial.payment.",
+        "financial.withdrawal.",
+        "financial.deposit.",
+        "financial.refund.",
+        "financial.reversal.",
+        "financial.payout.",
+        "financial.settlement.",
+        "financial.chargeback.",
+        "financial.reconciliation."
+      ],
+      "when": {
+        "path": "/metadata/financial/approvalRequired",
+        "equals": true
+      },
+      "requiredPaths": ["/approval/status"],
+      "recommendedPaths": ["/approval/workflowId", "/approval/approvers"]
+    },
+    {
+      "id": "FIN-MANUAL-001",
+      "description": "When the producer declares an operation to be a manual intervention, the event records what was altered and why.",
+      "rationale": "A manual intervention is an operator substituting their own judgement for the system's, and it is the single most sensitive class of financial event because it leaves no upstream business record to reconcile against. The automated path has an order, an instruction or a schedule behind it; the manual path has a person. Recording the change makes the intervention measurable against the state it replaced, and recording the justification is the only chance to capture the operator's intent, which no later reviewer can reconstruct. The flag is set by the producer because only the producer knows which of its code paths is the manual one.",
+      "severity": "error",
+      "events": ["financial.limit.create", "financial.limit.delete", "financial.limit.update"],
+      "eventPrefixes": [
+        "financial.transfer.",
+        "financial.payment.",
+        "financial.withdrawal.",
+        "financial.deposit.",
+        "financial.refund.",
+        "financial.reversal.",
+        "financial.payout.",
+        "financial.settlement.",
+        "financial.chargeback.",
+        "financial.reconciliation."
+      ],
+      "when": {
+        "path": "/metadata/financial/manual",
+        "equals": true
+      },
+      "requiredPaths": ["/reason", "/change"],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "FIN-RECON-001",
+      "description": "A reconciliation event names the reconciliation it belongs to.",
+      "rationale": "Reconciliation is the control that proves the producer's own record of money agrees with somebody else's. Its events are only meaningful as a set: a start, a set of findings and a completion together state what was compared and what the comparison concluded. An event that does not name its run cannot be placed in that set, so the trail records that reconciliation happened without recording what any of it decided, and a break found in one period becomes indistinguishable from a break found in another.",
+      "severity": "error",
+      "eventPrefixes": ["financial.reconciliation."],
+      "requiredMetadata": [
+        {
+          "path": "/financial/reconciliationId",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/request/correlationId"]
+    },
+    {
+      "id": "FIN-RECON-002",
+      "description": "A reconciliation adjustment records the change it made to the books, the amount and currency involved, and why the correction was accepted.",
+      "rationale": "An adjustment is the one reconciliation operation that moves recorded value without a business transaction behind it: the books are altered to agree with an external record. That makes it the natural hiding place for a loss nobody wants to explain, and the natural place for a genuine correction to be mistaken for one. The before and after state, the size of the correction and the stated justification are what let a later reviewer tell those two apart, and none of them can be recovered once the balances have moved on.",
+      "severity": "error",
+      "events": ["financial.reconciliation.adjust"],
+      "requiredPaths": ["/change", "/reason"],
+      "requiredMetadata": [
+        {
+          "path": "/financial/amount",
+          "type": "number"
+        },
+        {
+          "path": "/financial/currency",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "FIN-LIMIT-001",
+      "description": "A change to a transaction limit records the kind of limit, its before and after state, and why it was changed.",
+      "rationale": "A limit is a preventive control, so changing one changes what every future transaction is allowed to do. Raising a ceiling shortly before a large movement and lowering it afterwards is the classic shape of a limit abused rather than administered, and it is visible only when the transition itself is recorded: an event stating the resulting value alone cannot show how far the control moved or that it moved back. The kind of limit is required because a daily aggregate ceiling and a single-transaction ceiling are different controls that deployments name differently, and a reviewer cannot infer which one changed from a number. The rule selects the three mutating operations by name rather than the whole `financial.limit.` family, because a limit check runs on every transaction: governing `financial.limit.check` would put the profile's heaviest requirements on its highest-volume event, and the requirement would be switched off rather than met.",
+      "severity": "error",
+      "events": ["financial.limit.create", "financial.limit.update", "financial.limit.delete"],
+      "requiredPaths": ["/change", "/reason"],
+      "requiredMetadata": [
+        {
+          "path": "/financial/limitType",
+          "type": "string"
+        }
+      ],
+      "recommendedPaths": ["/approval"]
+    }
+  ]
+}

package/profiles/identity-and-access-management/0.1/profile.json

@@ -0,0 +1,120 @@
+{
+  "profileVersion": "0.1",
+  "name": "identity-and-access-management",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "Identity and Access Management Profile",
+  "description": "Additional conformance requirements for identity and access management audit events. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it.",
+  "rules": [
+    {
+      "id": "IAM-CORE-001",
+      "description": "Every identity operation records the authorization decision that permitted it.",
+      "rationale": "An access change without a recorded decision cannot be reviewed: nothing distinguishes a change a policy allowed from one that bypassed policy entirely.",
+      "severity": "error",
+      "eventPrefixes": ["identity."],
+      "requiredPaths": ["/authorization"]
+    },
+    {
+      "id": "IAM-CORE-002",
+      "description": "Every identity operation records why it was performed and how it correlates with the request that caused it.",
+      "rationale": "Access changes are reviewed long after the fact, by someone who cannot ask the actor what they were doing.",
+      "severity": "error",
+      "eventPrefixes": ["identity."],
+      "recommendedPaths": ["/reason", "/request/correlationId"]
+    },
+    {
+      "id": "IAM-ROLE-001",
+      "description": "Role assignment and revocation identify the role and whether it is privileged, and record a justification.",
+      "rationale": "The privileged flag is what makes a later reviewer able to separate routine access changes from the ones that matter, without knowing the operator's role catalogue.",
+      "severity": "error",
+      "events": ["identity.role.assign", "identity.role.revoke"],
+      "requiredPaths": ["/authorization", "/reason"],
+      "requiredMetadata": [
+        { "path": "/role/id", "type": "string" },
+        { "path": "/role/privileged", "type": "boolean" }
+      ],
+      "recommendedPaths": ["/approval", "/request/correlationId"]
+    },
+    {
+      "id": "IAM-ROLE-002",
+      "description": "A privileged role change is approved and performed from a multi-factor authenticated session.",
+      "rationale": "Privileged access is the control that protects every other control; granting it on the strength of a single factor and one person's judgement is the failure this rule exists to make visible.",
+      "severity": "error",
+      "events": ["identity.role.assign", "identity.role.revoke"],
+      "when": { "path": "/metadata/role/privileged", "equals": true },
+      "requiredPaths": ["/approval", "/authentication"],
+      "requiredValues": [{ "path": "/authentication/mfa", "equals": true }]
+    },
+    {
+      "id": "IAM-PERM-001",
+      "description": "Permission grants and revocations identify the permission, its scope and whether it is privileged.",
+      "rationale": "A permission without a scope cannot be assessed: the same permission over one record and over an entire tenant are different operations.",
+      "severity": "error",
+      "eventPrefixes": ["identity.permission."],
+      "requiredPaths": ["/authorization", "/reason"],
+      "requiredMetadata": [
+        { "path": "/permission/id", "type": "string" },
+        { "path": "/permission/scope", "type": "string" },
+        { "path": "/permission/privileged", "type": "boolean" }
+      ],
+      "recommendedPaths": ["/approval", "/request/correlationId"]
+    },
+    {
+      "id": "IAM-PERM-002",
+      "description": "A privileged permission change is approved and performed from a multi-factor authenticated session.",
+      "rationale": "Direct permission grants bypass the role model, so they warrant the same scrutiny as a privileged role change.",
+      "severity": "error",
+      "eventPrefixes": ["identity.permission."],
+      "when": { "path": "/metadata/permission/privileged", "equals": true },
+      "requiredPaths": ["/approval", "/authentication"],
+      "requiredValues": [{ "path": "/authentication/mfa", "equals": true }]
+    },
+    {
+      "id": "IAM-USER-001",
+      "description": "User lifecycle events record the kind of principal the account represents.",
+      "rationale": "Distinguishing an employee account from a contractor, partner or test account is what makes an access review answerable. It requires no personal data.",
+      "severity": "error",
+      "events": ["identity.user.create", "identity.user.disable", "identity.user.delete"],
+      "requiredMetadata": [{ "path": "/user/type", "type": "string" }]
+    },
+    {
+      "id": "IAM-USER-002",
+      "description": "Disabling or deleting an account records why.",
+      "rationale": "Account removal is indistinguishable from account suppression without a stated reason, and the two have very different implications.",
+      "severity": "error",
+      "events": ["identity.user.disable", "identity.user.delete"],
+      "requiredPaths": ["/reason"],
+      "recommendedPaths": ["/approval"]
+    },
+    {
+      "id": "IAM-SVC-001",
+      "description": "Service account lifecycle events record the account's purpose and a human owner.",
+      "rationale": "Unowned service accounts outlive the systems that needed them. Recording an owner at creation is the only point at which the answer is known.",
+      "severity": "error",
+      "events": ["identity.service-account.create", "identity.service-account.disable"],
+      "requiredMetadata": [
+        { "path": "/serviceAccount/purpose", "type": "string" },
+        { "path": "/serviceAccount/ownerId", "type": "string" }
+      ]
+    },
+    {
+      "id": "IAM-SVC-002",
+      "description": "Service account creation records when the account is expected to expire.",
+      "rationale": "A recorded expiry turns an indefinite credential into a reviewable one. It is recommended rather than required because not every service account can be time-bound.",
+      "severity": "error",
+      "events": ["identity.service-account.create"],
+      "recommendedPaths": ["/metadata/serviceAccount/expiresAt"]
+    },
+    {
+      "id": "IAM-CRED-001",
+      "description": "Credential rotation records the authorization, the justification and the kind of credential rotated.",
+      "rationale": "The kind of credential determines the blast radius of the rotation. The credential itself must never appear in the event; see the profile documentation.",
+      "severity": "error",
+      "events": ["identity.credential.rotate"],
+      "requiredPaths": ["/authorization", "/reason"],
+      "requiredMetadata": [{ "path": "/credential/type", "type": "string" }],
+      "recommendedPaths": ["/request/correlationId"]
+    }
+  ]
+}