@openauditmodel/cli 0.3.0 → 0.4.0

package/dist/conformance/src/profiles/coverage.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"coverage.js","sourceRoot":"","sources":["../../../../conformance/src/profiles/coverage.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,OAAO,EAAE,cAAc,EAAE,MAAM,oBAAoB,CAAC;AACpD,OAAO,EAAE,SAAS,EAAE,WAAW,EAAE,MAAM,mBAAmB,CAAC;AAC3D,OAAO,EACL,uBAAuB,GAKxB,MAAM,YAAY,CAAC;AAwDpB;;;;;;;;GAQG;AACH,MAAM,UAAU,iBAAiB,CAC/B,MAA0B,EAC1B,OAAsC,EACtC,OAA0B;IAE1B,MAAM,QAAQ,GAAG,IAAI,GAAG,EAAkB,CAAC;IAC3C,MAAM,OAAO,GAAG,IAAI,GAAG,EAAkB,CAAC;IAC1C,MAAM,MAAM,GAAG,IAAI,GAAG,EAAkB,CAAC;IACzC,MAAM,UAAU,GAAG,IAAI,GAAG,EAAkB,CAAC;IAC7C,MAAM,aAAa,GAAG,IAAI,GAAG,EAAU,CAAC;IAExC,KAAK,MAAM,IAAI,IAAI,OAAO,CAAC,KAAK,EAAE,CAAC;QACjC,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC;QACzB,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC;QACxB,MAAM,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC;IACzB,CAAC;IAED,KAAK,MAAM,CAAC,KAAK,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,EAAE,EAAE,CAAC;QAC9C,MAAM,MAAM,GAAG,OAAO,CAAC,KAAK,CAAC,CAAC;QAC9B,MAAM,IAAI,GAAG,SAAS,CAAC,KAAK,CAAC,CAAC;QAC9B,IAAI,IAAI,KAAK,SAAS,EAAE,CAAC;YACvB,UAAU,CAAC,GAAG,CAAC,IAAI,EAAE,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;QACxD,CAAC;QAED,yEAAyE;QACzE,wEAAwE;QACxE,IAAI,MAAM,KAAK,SAAS,IAAI,MAAM,CAAC,MAAM,KAAK,cAAc,IAAI,IAAI,KAAK,SAAS,EAAE,CAAC;YACnF,SAAS;QACX,CAAC;QAED,MAAM,KAAK,GAAG,WAAW,CAAC,OAAO,EAAE,IAAI,CAAC,CAAC;QACzC,IAAI,KAAK,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YACrB,aAAa,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;QAC1B,CAAC;QAED,MAAM,OAAO,GAAG,IAAI,GAAG,CAAC,MAAM,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC;QACxE,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;YACzB,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;YACxD,IAAI,IAAI,CAAC,IAAI,KAAK,SAAS,IAAI,cAAc,CAAC,KAAK,EAAE,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;gBAChE,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;YACxD,CAAC;YACD,IAAI,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,EAAE,CAAC;gBACzB,MAAM,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,MAAM,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;YACtD,CAAC;QACH,CAAC;IACH,CAAC;IAED,MAAM,OAAO,GAAmB,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;QAC3D,MAAM,EAAE,IAAI,CAAC,EAAE;QACf,QAAQ,EAAE,IAAI,CAAC,QAAQ,IAAI,OAAO;QAClC,QAAQ,EAAE,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC;QACpC,OAAO,EAAE,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC;QAClC,MAAM,EAAE,MAAM,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,CAAC;KACjC,CAAC,CAAC,CAAC;IAEJ,MAAM,KAAK,GAAwB,CAAC,GAAG,UAAU,CAAC,OAAO,EAAE,CAAC;SACzD,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,KAAK,CAAC,EAAE,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,KAAK,EAAE,QAAQ,EAAE,aAAa,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;SACpF,IAAI,CAAC,CAAC,IAAI,EAAE,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,MAAM,GAAG,IAAI,CAAC,MAAM,IAAI,IAAI,CAAC,IAAI,CAAC,aAAa,CAAC,KAAK,CAAC,IAAI,EAAE,IAAI,CAAC,CAAC,CAAC;IAElG,OAAO;QACL,OAAO,EAAE,EAAE,IAAI,EAAE,OAAO,CAAC,IAAI,EAAE,OAAO,EAAE,OAAO,CAAC,OAAO,EAAE,MAAM,EAAE,OAAO,CAAC,MAAM,EAAE;QACjF,MAAM,EAAE,uBAAuB,CAAC,OAAO,CAAC;QACxC,KAAK,EAAE;YACL,KAAK,EAAE,OAAO,CAAC,KAAK,CAAC,MAAM;YAC3B,QAAQ,EAAE,OAAO,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,GAAG,CAAC,CAAC,CAAC,MAAM;YAC5D,OAAO,EAAE,OAAO,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,OAAO,GAAG,CAAC,CAAC,CAAC,MAAM;YAC1D,aAAa,EAAE,OAAO,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,MAAM,CAAC;YACvF,uBAAuB,EAAE,OAAO;iBAC7B,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,GAAG,CAAC,IAAI,IAAI,CAAC,OAAO,KAAK,CAAC,CAAC;iBACzD,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,MAAM,CAAC;SAC9B;QACD,OAAO;QACP,KAAK;QACL,UAAU,EAAE;YACV,QAAQ,EAAE,KAAK,CAAC,MAAM;YACtB,QAAQ,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC,MAAM;YACxD,UAAU,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC,MAAM;SAC5D;KACF,CAAC;AACJ,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openauditmodel/cli",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Conformance toolchain for OpenAuditModel: validate audit events against the canonical JSON Schema, verify tamper-evidence, lint for leaked secrets and check domain profiles. Offline and deterministic.",
   "keywords": [
     "audit",
@@ -52,7 +52,12 @@
     "check:profile": "npm run build && node dist/conformance/src/cli.js check-profile examples/profiles/identity-and-access-management/valid --profile identity-and-access-management && node dist/conformance/src/cli.js check-profile examples/profiles/document-management/valid --profile document-management && node dist/conformance/src/cli.js check-profile examples/profiles/incident-management/valid --profile incident-management && node dist/conformance/src/cli.js check-profile examples/profiles/message-broker-management/valid --profile message-broker-management && node dist/conformance/src/cli.js check-profile examples/profiles/deployment-and-change-management/valid --profile deployment-and-change-management && node dist/conformance/src/cli.js check-profile examples/profiles/financial-transaction-management/valid --profile financial-transaction-management && node dist/conformance/src/cli.js check-profile examples/profiles/secrets-and-key-management/valid --profile secrets-and-key-management && node dist/conformance/src/cli.js check-profile examples/profiles/customer-and-account-management/valid --profile customer-and-account-management && node dist/conformance/src/cli.js check-profile examples/profiles/backup-and-recovery/valid --profile backup-and-recovery && node dist/conformance/src/cli.js check-profile examples/profiles/api-and-integration-management/valid --profile api-and-integration-management",
     "fixtures:integrity": "npm run build && node dist/conformance/tools/generate-integrity-fixtures.js && prettier --write examples/integrity",
     "fixtures:check": "npm run build && node dist/conformance/tools/generate-integrity-fixtures.js --check",
-    "verify": "npm run format:check && npm run lint && npm run test && npm run validate:valid && npm run verify:integrity && npm run lint:privacy && npm run check:profile && npm run fixtures:check && npm run mcp:check-generated && npm run package:verify && npm run package:smoke",
+    "kit:build": "npm run build && node dist/conformance/tools/generate-kit.js && prettier --write conformance-kit",
+    "kit:check": "npm run build && node dist/conformance/tools/generate-kit.js --check",
+    "profiles:lint": "npm run build && node dist/conformance/tools/lint-profiles.js",
+    "profiles:archive": "npm run build && node dist/conformance/tools/archive-profile-versions.js",
+    "profiles:check-archive": "npm run build && node dist/conformance/tools/archive-profile-versions.js --check",
+    "verify": "npm run format:check && npm run lint && npm run test && npm run validate:valid && npm run verify:integrity && npm run lint:privacy && npm run check:profile && npm run fixtures:check && npm run profiles:check-archive && npm run profiles:lint && npm run kit:check && npm run mcp:check-generated && npm run package:verify && npm run package:smoke",
     "mcp:generate": "npm run generate --workspace mcp",
     "mcp:check-generated": "npm run generate:check --workspace mcp",
     "mcp:start": "npm run build && node dist/mcp/src/index.js",

package/profiles/README.md

@@ -75,6 +75,48 @@ documents**; it is not part of the canonical audit event schema and never constr
 `coreVersions` lists the core versions the profile applies to; an event declaring any other
 `specVersion` is **not applicable** rather than in violation.
 
+### Versions are filed, and a filed version never changes
+
+**Changing a profile's rules MUST bump its `version`.** [ADR 0008](../decisions/0008-declarative-profile-conformance.md)
+records why: adding a rule is a breaking change for producers, in the same sense as adding a required
+core field, because events that conformed may stop conforming.
+
+Each version is filed at `profiles/<name>/<version>/profile.json` when it is published, and a filed
+copy is never edited afterwards. The site publishes every filed version, so revising a profile adds
+an address rather than withdrawing the one consumers already have — the site serves these documents
+with a year-long `immutable` cache lifetime, and a URL that answered yesterday must not 404 today.
+
+The archive is what enforces the bump. Change a rule without changing `version` and the working
+document no longer matches the copy filed under that version, which fails `npm run verify`. There are
+two ways to make it pass: bump the version, or revert the change.
+
+```bash
+npm run profiles:archive        # file the current version of every profile
+npm run profiles:check-archive  # compare each profile with its filed copy
+npm run profiles:lint           # report defects the definition schema cannot express
+```
+
+### What the lint checks
+
+The definition schema decides whether a profile document is well formed. It cannot decide whether the
+document says what its author meant, and three of the ways it can fail to are silent:
+
+|                                        |                                                                                                                                         |
+| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| A rule id declared twice               | Selection deduplicates by id, so the later rule is never evaluated and its requirements vanish. The event is reported **conforming**    |
+| A rule that states no requirement      | An event is `not-applicable` only while no rule selects it. One requirement-free rule makes it governed and satisfied                   |
+| A condition on a path no rule requires | An absent condition path means the condition does not hold, so a producer that never writes the flag escapes the requirement in silence |
+
+The lint also rejects pointers that can never resolve — an empty reference token, and a
+`requiredMetadata` path beginning with `/metadata`, which is concatenated into `/metadata/metadata/…`
+— and requirements that contradict each other. Those are errors. Redundant selectors and unreachable
+prefixes are warnings, and warnings never fail the build.
+
+A version bump is not complete until three things move together: `version` in `profile.json`, a filed
+copy under the new version, and the profile's allowlist entry in
+`mcp/scripts/generate-resource-manifest.mjs`, which carries the version in the resource URI it serves.
+A test holds each of them in place.
+
 ### Rules
 
 Each rule has an `id` and a `description`, and MAY have a `rationale` and a `severity`.

package/profiles/api-and-integration-management/0.1/profile.json

@@ -0,0 +1,258 @@
+{
+  "profileVersion": "0.1",
+  "name": "api-and-integration-management",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "API and Integration Management Profile",
+  "description": "Additional conformance requirements for the administration of API credentials, webhook subscriptions and third-party integrations: issuing and revoking API keys, creating and reconfiguring webhooks, connecting, reauthorizing and disconnecting external systems, and starting or cancelling integration syncs. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it. Data-plane traffic is deliberately not governed: ordinary API requests, webhook deliveries and routine integration polling match no rule in this profile.",
+  "rules": [
+    {
+      "id": "INTEGRATION-CORE-001",
+      "description": "Every governed API, webhook or integration administration event records the authorization decision that permitted it and the kind of integration point it acted on.",
+      "rationale": "An integration is a standing hole in a trust boundary, and the events that open, widen or close one are the only record that the hole was opened deliberately. Without a recorded decision nothing distinguishes a change a policy allowed from one that bypassed policy, and without the kind of integration point a reviewer cannot tell whether the event concerns a credential someone holds, a callback that pushes data outward, or a connector that pulls data in — three operations with entirely different blast radii that otherwise look identical in a report.",
+      "severity": "error",
+      "events": [
+        "api-key.create",
+        "api-key.rotate",
+        "api-key.revoke",
+        "api-key.delete",
+        "webhook.create",
+        "webhook.update",
+        "webhook.enable",
+        "webhook.disable",
+        "webhook.delete",
+        "webhook.test",
+        "integration.connect",
+        "integration.disconnect",
+        "integration.enable",
+        "integration.disable",
+        "integration.reauthorize",
+        "integration.sync.start",
+        "integration.sync.cancel"
+      ],
+      "eventPrefixes": ["integration.configuration."],
+      "requiredPaths": ["/authorization"],
+      "requiredMetadata": [{ "path": "/integration/type", "type": "string" }]
+    },
+    {
+      "id": "INTEGRATION-CORE-002",
+      "description": "A governed integration event should record why it happened, whether it was approved, which external party it concerns, 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 scheduled rotation has no business justification beyond the schedule, because most integration changes legitimately need no approval, and because a first-party API key has no external counterparty to name. A missing one of these should prompt a question, not fail a build.",
+      "severity": "warning",
+      "events": [
+        "api-key.create",
+        "api-key.rotate",
+        "api-key.revoke",
+        "api-key.delete",
+        "webhook.create",
+        "webhook.update",
+        "webhook.enable",
+        "webhook.disable",
+        "webhook.delete",
+        "webhook.test",
+        "integration.connect",
+        "integration.disconnect",
+        "integration.enable",
+        "integration.disable",
+        "integration.reauthorize",
+        "integration.sync.start",
+        "integration.sync.cancel"
+      ],
+      "eventPrefixes": ["integration.configuration."],
+      "recommendedPaths": [
+        "/reason",
+        "/approval",
+        "/request/correlationId",
+        "/metadata/integration/provider"
+      ]
+    },
+    {
+      "id": "INTEGRATION-CORE-003",
+      "description": "When the producer declares that local policy required approval for this change, the event carries the approval and its state.",
+      "rationale": "Approval requirements for integration changes are set by the operator, not by this specification: one organization gates every outbound webhook, another gates none. So the profile does not guess. When a producer has declared that approval was required, an event that omits the approval record is evidence that the control was skipped or that the trail cannot show it was honoured — and those two are indistinguishable after the fact, which is exactly the ambiguity an audit trail exists to remove. The status is required alongside the object because an approval with no state answers nothing.",
+      "severity": "error",
+      "events": [
+        "api-key.create",
+        "api-key.rotate",
+        "api-key.revoke",
+        "api-key.delete",
+        "webhook.create",
+        "webhook.update",
+        "webhook.enable",
+        "webhook.disable",
+        "webhook.delete",
+        "webhook.test",
+        "integration.connect",
+        "integration.disconnect",
+        "integration.enable",
+        "integration.disable",
+        "integration.reauthorize",
+        "integration.sync.start",
+        "integration.sync.cancel"
+      ],
+      "eventPrefixes": ["integration.configuration."],
+      "when": { "path": "/metadata/integration/approvalRequired", "equals": true },
+      "requiredPaths": ["/approval", "/approval/status"]
+    },
+    {
+      "id": "INTEGRATION-AUTHN-001",
+      "description": "A credential or connection-authorization operation performed by a human user records how that user was authenticated.",
+      "rationale": "Issuing, rotating or revoking an API key and authorizing or tearing down a connection are the operations an attacker performs to establish or remove persistence. When a person did it, the strength of the session behind the action is the fact that separates a routine administrative change from a change made through a stolen cookie, and it can never be reconstructed later. The requirement is conditional on the actor being a person because a scheduled rotation worker has no interactive session to describe, and a rule that demanded one would be switched off rather than met.",
+      "severity": "error",
+      "events": [
+        "api-key.create",
+        "api-key.rotate",
+        "api-key.revoke",
+        "api-key.delete",
+        "integration.connect",
+        "integration.reauthorize",
+        "integration.disconnect"
+      ],
+      "when": { "path": "/actor/type", "equals": "user" },
+      "requiredPaths": ["/authentication"]
+    },
+    {
+      "id": "INTEGRATION-AUTHN-002",
+      "description": "A credential or connection-authorization operation performed by an administrator records how that administrator was authenticated.",
+      "rationale": "This states the same requirement as INTEGRATION-AUTHN-001 for the other human principal type in the core model. It exists as a separate rule because the v0.1 rule language permits exactly one equality condition per rule and has no disjunction, so `user` and `admin` cannot be expressed in one condition. Splitting the rule is the honest way to cover both; collapsing them by dropping the condition would demand an interactive session from every automated rotation worker.",
+      "severity": "error",
+      "events": [
+        "api-key.create",
+        "api-key.rotate",
+        "api-key.revoke",
+        "api-key.delete",
+        "integration.connect",
+        "integration.reauthorize",
+        "integration.disconnect"
+      ],
+      "when": { "path": "/actor/type", "equals": "admin" },
+      "requiredPaths": ["/authentication"]
+    },
+    {
+      "id": "INTEGRATION-KEY-001",
+      "description": "An API key lifecycle event names the credential it acted on through a non-secret reference.",
+      "rationale": "A key rotation that does not say which key rotated cannot be tied to the calls made before and after it, so neither the exposure window nor the callers that broke can be established. The reference is a handle the producer can resolve; it is never the key. The profile requires the reference precisely so that producers have somewhere non-sensitive to put the answer. Nothing enforces that discipline: the privacy linter catches published credential formats and high-entropy values, but a producer who stores a real key here may well pass it, so this is a requirement on the producer rather than a check.",
+      "severity": "error",
+      "events": ["api-key.create", "api-key.rotate", "api-key.revoke", "api-key.delete"],
+      "requiredMetadata": [{ "path": "/integration/credentialReference", "type": "string" }]
+    },
+    {
+      "id": "INTEGRATION-KEY-002",
+      "description": "Issuing or rotating an API key should record what the key may do and when it stops working.",
+      "rationale": "Scope and expiry are what turn a credential into a reviewable one: an unbounded, never-expiring key is the finding, and the only moment the answer is known is issuance. Both are recommended rather than required because plenty of legitimate deployments issue keys with no expiry by design, and because scope vocabularies differ enough between products that a required field would be filled with a placeholder.",
+      "severity": "warning",
+      "events": ["api-key.create", "api-key.rotate"],
+      "recommendedPaths": [
+        "/metadata/integration/scope",
+        "/metadata/integration/expiresAt",
+        "/resource/ownerId"
+      ]
+    },
+    {
+      "id": "INTEGRATION-REVOKE-001",
+      "description": "Revoking, deleting, disabling or disconnecting an API credential, webhook or integration is justified.",
+      "rationale": "Withdrawal breaks something that was working for somebody, and the three explanations — planned decommission, incident containment, and mistake — produce identical events unless the reason is recorded. This is also the class of operation most often performed under pressure, when the person who could explain it is busy, so the justification has to be captured at the time or not at all.",
+      "severity": "error",
+      "events": [
+        "api-key.revoke",
+        "api-key.delete",
+        "webhook.disable",
+        "webhook.delete",
+        "integration.disconnect",
+        "integration.disable",
+        "integration.sync.cancel"
+      ],
+      "requiredPaths": ["/reason"]
+    },
+    {
+      "id": "INTEGRATION-HOOK-001",
+      "description": "A webhook administration event identifies the subscription and classifies the destination the callback is delivered to.",
+      "rationale": "A webhook is an instruction to push data out of the system on an ongoing basis, so the single fact that determines its risk is where the data goes. The profile requires a classification rather than the callback URL on purpose: delivery URLs routinely carry signed access parameters or shared secrets in their path or query string, so recording one turns the audit trail into a credential store. A class such as an internal service, a partner network or the public internet answers the reviewer's question without carrying anything an attacker can use.",
+      "severity": "error",
+      "events": [
+        "webhook.create",
+        "webhook.update",
+        "webhook.enable",
+        "webhook.disable",
+        "webhook.delete",
+        "webhook.test"
+      ],
+      "requiredMetadata": [
+        { "path": "/integration/webhookId", "type": "string" },
+        { "path": "/integration/endpointClass", "type": "string" }
+      ]
+    },
+    {
+      "id": "INTEGRATION-CONFIG-001",
+      "description": "Reconfiguring a webhook subscription or an integration records the change itself.",
+      "rationale": "An update event that says only that something changed is not reviewable: retry behaviour, event selection, field mapping and destination are all reached through the same operation, and they are not equally consequential. The core `/change` object is where the difference belongs. The changed field names are recommended alongside it because they are the cheapest useful form of the answer and they carry no configuration values; before and after states are neither required nor recommended, because integration configuration frequently contains endpoints and headers that must not be copied into an audit event.",
+      "severity": "error",
+      "events": ["webhook.update"],
+      "eventPrefixes": ["integration.configuration."],
+      "requiredPaths": ["/change"],
+      "recommendedPaths": ["/change/changedFields"]
+    },
+    {
+      "id": "INTEGRATION-CONN-001",
+      "description": "An integration lifecycle, configuration or sync event identifies the connection instance and the external party on the other side of it.",
+      "rationale": "Organizations run many connections to the same kind of system and several to the same provider, so neither the provider name nor the resource identifier alone locates the integration that changed. Recording both is what allows a reviewer to answer the question that actually gets asked after a third-party compromise — which of our connections to that party were live, and who changed them — without needing the producer's internal topology.",
+      "severity": "error",
+      "events": [
+        "integration.connect",
+        "integration.disconnect",
+        "integration.enable",
+        "integration.disable",
+        "integration.reauthorize",
+        "integration.sync.start",
+        "integration.sync.cancel"
+      ],
+      "eventPrefixes": ["integration.configuration."],
+      "requiredMetadata": [
+        { "path": "/integration/connectionId", "type": "string" },
+        { "path": "/integration/provider", "type": "string" }
+      ]
+    },
+    {
+      "id": "INTEGRATION-FLOW-001",
+      "description": "Connecting, reauthorizing, starting a sync or cancelling a sync records the correlation identifier that ties the steps of the workflow together.",
+      "rationale": "These four operations are never a single event. A connection is a redirect, a consent, a callback and a token exchange; a sync is a start, a run and an end. Reconstructing what happened means reassembling those steps, and a producer-assigned correlation identifier is the only thing that makes that possible. It is required here and merely recommended elsewhere because elsewhere there is nothing to correlate with. This is deliberately not a trace identifier: correlation is a value the producer stamps on related events, and requiring `traceId` would make conformance depend on distributed tracing being deployed.",
+      "severity": "error",
+      "events": [
+        "integration.connect",
+        "integration.reauthorize",
+        "integration.sync.start",
+        "integration.sync.cancel"
+      ],
+      "requiredPaths": ["/request/correlationId"]
+    },
+    {
+      "id": "INTEGRATION-FAIL-001",
+      "description": "A failed integration operation classifies the failure, not only names it.",
+      "rationale": "The core model already requires a failure code. A code alone is a producer-defined string, so a reviewer looking at a burst of failures cannot tell whether an integration is rejecting credentials, being denied permission, timing out or hitting a quota without learning that producer's vocabulary first. The coarse classification is what makes 'is this a credential problem or a network problem?' answerable across products, and that question decides whether a failure burst is an outage or an attack.",
+      "severity": "error",
+      "events": [
+        "api-key.create",
+        "api-key.rotate",
+        "api-key.revoke",
+        "api-key.delete",
+        "webhook.create",
+        "webhook.update",
+        "webhook.enable",
+        "webhook.disable",
+        "webhook.delete",
+        "webhook.test",
+        "integration.connect",
+        "integration.disconnect",
+        "integration.enable",
+        "integration.disable",
+        "integration.reauthorize",
+        "integration.sync.start",
+        "integration.sync.cancel"
+      ],
+      "eventPrefixes": ["integration.configuration."],
+      "when": { "path": "/event/outcome", "equals": "failure" },
+      "requiredPaths": ["/event/error/type"]
+    }
+  ]
+}

package/profiles/backup-and-recovery/0.1/profile.json

@@ -0,0 +1,178 @@
+{
+  "profileVersion": "0.1",
+  "name": "backup-and-recovery",
+  "version": "0.1",
+  "status": "experimental",
+  "coreVersions": ["0.1"],
+  "title": "Backup and Recovery Profile",
+  "description": "Additional conformance requirements for backup, snapshot, restore, recovery and failover audit events: creating and verifying recovery points, deleting and expiring them, restoring data, moving service between sites, and changing the policy that decides what is protected. Every requirement adds to the OpenAuditModel Core Specification; none relaxes it. Data-plane events such as chunk writes, progress reports and replication heartbeats are deliberately not governed.",
+  "rules": [
+    {
+      "id": "BACKUP-CORE-001",
+      "description": "Every governed backup, snapshot, restore, recovery or backup-policy operation records the authorization decision that permitted it.",
+      "rationale": "Backup and recovery tooling holds standing access to the most complete copy of an organization's data and to the switch that moves production between sites. Without a recorded decision, nothing in the trail separates an operation a policy permitted from one that ran because the backup service could. An operation performed by a scheduler is not exempt: it records the decision the schedule represents, or `not-applicable` where the producer made no decision at all, so that the absence of a control is stated rather than inferred from a missing field.",
+      "severity": "error",
+      "events": [
+        "backup.create",
+        "backup.complete",
+        "backup.verify",
+        "backup.delete",
+        "backup.expire",
+        "snapshot.create",
+        "snapshot.delete",
+        "restore.start",
+        "restore.complete",
+        "recovery.start",
+        "recovery.complete",
+        "recovery.failover",
+        "recovery.failback"
+      ],
+      "eventPrefixes": ["backup.policy."],
+      "requiredPaths": ["/authorization"]
+    },
+    {
+      "id": "BACKUP-CORE-002",
+      "description": "A governed operation should record why it happened and how it correlates with the wider recovery workflow.",
+      "rationale": "Backup and recovery operations are multi-stage by nature: a restore is a start and a completion, a failover is a sequence across storage, database and traffic layers, and each stage is usually emitted by a different component. A correlation identifier is what turns those events back into one operation. It is recommended rather than required because correlation infrastructure is not universal, and an appliance that emits events with no request context would otherwise be pushed to invent one. A justification is recommended everywhere and required on the operations that destroy or move data.",
+      "severity": "warning",
+      "events": [
+        "backup.create",
+        "backup.complete",
+        "backup.verify",
+        "backup.delete",
+        "backup.expire",
+        "snapshot.create",
+        "snapshot.delete",
+        "restore.start",
+        "restore.complete",
+        "recovery.start",
+        "recovery.complete",
+        "recovery.failover",
+        "recovery.failback"
+      ],
+      "eventPrefixes": ["backup.policy."],
+      "recommendedPaths": ["/reason", "/request/correlationId"]
+    },
+    {
+      "id": "BACKUP-SET-001",
+      "description": "A backup lifecycle event identifies the backup copy it acted on and the kind of copy it is.",
+      "rationale": "An identifier is what ties the event to the copy it describes; without it the trail records that a backup happened but not which one, and a later question about a specific recovery point has no answer. The kind of copy matters just as much, because a full, incremental, differential or transaction-log copy carry different consequences: deleting a full copy can invalidate every incremental that depends on it, while deleting one incremental usually does not. A reviewer cannot infer either fact from the event name.",
+      "severity": "error",
+      "events": [
+        "backup.create",
+        "backup.complete",
+        "backup.verify",
+        "backup.delete",
+        "backup.expire"
+      ],
+      "requiredMetadata": [
+        { "path": "/backup/backupId", "type": "string" },
+        { "path": "/backup/backupType", "type": "string" }
+      ],
+      "recommendedPaths": ["/metadata/backup/retentionClass"]
+    },
+    {
+      "id": "BACKUP-SET-002",
+      "description": "A backup run that completed successfully records the point in time the copy represents.",
+      "rationale": "A backup is only meaningful as a position on a timeline. Without the recovery point, the trail can say a copy exists but not what state it holds, and the question every recovery review begins with — how much data would be lost by restoring this copy — is unanswerable. The requirement is conditional on a successful outcome because a failed run produces no recovery point, and a rule that demanded one would force producers to fabricate a value for the failure case. The profile checks that the field is present and is a string; it cannot check that it is a valid timestamp or that it precedes the event time.",
+      "severity": "error",
+      "events": ["backup.complete"],
+      "when": { "path": "/event/outcome", "equals": "success" },
+      "requiredMetadata": [{ "path": "/backup/recoveryPoint", "type": "string" }],
+      "recommendedPaths": ["/metadata/backup/retentionClass"]
+    },
+    {
+      "id": "BACKUP-VERIFY-001",
+      "description": "A backup verification event records the verdict it reached about the copy.",
+      "rationale": "`event.outcome` says whether the verification ran; it does not say what the verification found. A check that completed successfully and proved the copy restorable, and a check that completed successfully and found it corrupt, are both `outcome: success`, and conflating them turns a verification programme into a record that jobs executed. The separate verdict is the only field that distinguishes an organization that tests its backups from one that tests whether its test harness runs. The profile does not fix the vocabulary of verdicts, because what verification means ranges from a checksum comparison to a full restore rehearsal.",
+      "severity": "error",
+      "events": ["backup.verify"],
+      "requiredMetadata": [{ "path": "/backup/verificationStatus", "type": "string" }],
+      "recommendedPaths": ["/evidence", "/metadata/backup/recoveryPoint"]
+    },
+    {
+      "id": "BACKUP-DELETE-001",
+      "description": "Deleting a backup copy or a snapshot before its retention has elapsed is justified.",
+      "rationale": "Deleting a recovery point removes the only means of returning to the state it held, and it is the operation an audit trail is least able to reconstruct afterwards, because the evidence is precisely what was removed. It is also the operation an attacker performs before the one they want to hide. A stated justification is what separates a deliberate disposal from destruction of evidence, and it must be recorded at the moment of deletion because there is nothing left to ask afterwards. Approval is recommended rather than required: many deployments legitimately let an owner remove a failed or superseded copy.",
+      "severity": "error",
+      "events": ["backup.delete", "snapshot.delete"],
+      "requiredPaths": ["/reason"],
+      "recommendedPaths": ["/approval", "/metadata/backup/retentionClass"]
+    },
+    {
+      "id": "BACKUP-EXPIRE-001",
+      "description": "A retention-driven expiry records the retention class that disposed of the copy.",
+      "rationale": "An expiry claims that a copy was removed because a policy said its time was up, and that claim is the entire justification for the event. Recording the retention class is what makes the claim checkable: it lets a reviewer test the disposal against the policy that supposedly drove it, and it makes a deletion recorded under the wrong name visible, because an operator-initiated removal dressed as an expiry has no class to point at. Retention metadata is recommended across the rest of this profile and required only here, where it is the operation's reason for existing.",
+      "severity": "error",
+      "events": ["backup.expire"],
+      "requiredMetadata": [{ "path": "/backup/retentionClass", "type": "string" }]
+    },
+    {
+      "id": "BACKUP-SNAPSHOT-001",
+      "description": "A snapshot event identifies the snapshot it created or removed.",
+      "rationale": "Snapshots are the recovery point people actually reach for, because they are cheap enough to take before every risky change and fast enough to restore from. That also makes them numerous, and a snapshot event without an identifier is indistinguishable from every other snapshot event on the same resource. The identifier is what allows a restore to be traced back to the copy it used, and a deletion to be traced to the copy that is now gone.",
+      "severity": "error",
+      "events": ["snapshot.create", "snapshot.delete"],
+      "requiredMetadata": [{ "path": "/backup/snapshotId", "type": "string" }],
+      "recommendedPaths": ["/metadata/backup/recoveryPoint", "/metadata/backup/retentionClass"]
+    },
+    {
+      "id": "BACKUP-RESTORE-001",
+      "description": "A restore records why it was performed, which operation it belongs to, which copy it read from and the point in time it restored to.",
+      "rationale": "A restore overwrites live data with older data, so it is simultaneously a data-loss event and a recovery: everything written between the recovery point and the restore is discarded. Three facts make it reviewable and none can be reconstructed later. The source names the copy that was trusted, which is what an investigation needs when the copy turns out to have been compromised. The recovery point bounds what was lost. The justification separates a disaster recovery from a quiet reversal of someone else's work — the single most common way a restore is misused. The restore identifier ties the start and the completion into one operation across the components that emit them.",
+      "severity": "error",
+      "events": ["restore.start", "restore.complete"],
+      "requiredPaths": ["/reason"],
+      "requiredMetadata": [
+        { "path": "/backup/restoreId", "type": "string" },
+        { "path": "/backup/sourceId", "type": "string" },
+        { "path": "/backup/recoveryPoint", "type": "string" }
+      ],
+      "recommendedPaths": ["/approval", "/request/correlationId"]
+    },
+    {
+      "id": "BACKUP-RECOVERY-001",
+      "description": "A recovery or failover event identifies the recovery operation it belongs to.",
+      "rationale": "A recovery is never one event. Declaring it, moving storage, promoting a replica, redirecting traffic and standing the original site back up are separate operations, usually in separate systems, often hours apart and frequently performed by different people under pressure. The recovery identifier is what makes them one operation rather than an unexplained sequence, and it is the field a post-incident review depends on to reconstruct the order in which decisions were taken.",
+      "severity": "error",
+      "events": ["recovery.start", "recovery.complete", "recovery.failover", "recovery.failback"],
+      "requiredMetadata": [{ "path": "/backup/recoveryId", "type": "string" }],
+      "recommendedPaths": ["/request/correlationId", "/metadata/backup/recoveryPoint"]
+    },
+    {
+      "id": "BACKUP-FAILOVER-001",
+      "description": "A failover or failback records where service was moved to and why it was moved.",
+      "rationale": "A failover moves production service somewhere else. Without the destination the event says service moved but not where, which is useless during the incident and worse afterwards, when the question is which site was serving traffic at a given moment. Without a reason, a rehearsed drill, a planned maintenance move and an emergency response to an outage are the same event, and they demand entirely different scrutiny. The destination is recorded as a logical scope — a site, region, cluster or replica name — never as an endpoint, URL or connection string.",
+      "severity": "error",
+      "events": ["recovery.failover", "recovery.failback"],
+      "requiredPaths": ["/reason"],
+      "requiredMetadata": [{ "path": "/backup/targetScope", "type": "string" }],
+      "recommendedPaths": ["/approval", "/request/correlationId"]
+    },
+    {
+      "id": "BACKUP-APPROVAL-001",
+      "description": "When the producer declares that local policy required approval, the operation carries the approval record.",
+      "rationale": "This profile does not decide which deployments need an approval before a destructive deletion, a production restore or a failover; that is an organizational judgement, and a rule that imposed one answer would describe a single company's process and be switched off everywhere else. The producer declares the answer, and the profile enforces the consequence: an event that states approval was required and carries no approval record documents an operation performed without the control its own system said was needed. That gap is exactly what a review is looking for, and it is invisible unless the declaration and the record are held to each other.",
+      "severity": "error",
+      "events": [
+        "backup.delete",
+        "snapshot.delete",
+        "restore.start",
+        "recovery.failover",
+        "recovery.failback"
+      ],
+      "when": { "path": "/metadata/backup/approvalRequired", "equals": true },
+      "requiredPaths": ["/approval"]
+    },
+    {
+      "id": "BACKUP-POLICY-001",
+      "description": "A change to a backup policy records the policy, what changed and why.",
+      "rationale": "A backup policy decides what is protected, how often and for how long, so editing it changes future recoverability without touching any data. The damage surfaces only when a recovery is attempted, which may be months later, and by then the event that caused it is one line in a change log. Recording the transition in `change` is what makes it possible to say what protection was reduced rather than merely that a policy was edited, and the justification is what distinguishes a deliberate cost decision from a silent weakening of the organization's ability to recover.",
+      "severity": "error",
+      "eventPrefixes": ["backup.policy."],
+      "requiredPaths": ["/change", "/reason"],
+      "requiredMetadata": [{ "path": "/backup/policyId", "type": "string" }],
+      "recommendedPaths": ["/approval", "/metadata/backup/retentionClass"]
+    }
+  ]
+}