5.4.2.3 Audit

The Audit domain of access. The record of every privileged action taken in the Console or through an admin API of any system: who did what, when, with which capability. Systems write the row in the same transaction as the change and publish it; access consolidates the rows and serves them here. It is one API, with its own contract and its own version.

5.4.2.3.1 Versions¶

The resources follow the data model. Read-only. The row is written by the system that makes the change, in the same transaction, and reaches access as the event platform_audit_event.recorded.v1; a synchronous call would break the same-transaction rule. Each system publishes on its own topic, <system>.audit.v1 in its own project (decided 2026-11-11), where only its backend and its relay may publish: Pub/Sub does not carry who published a message, so one shared topic could not prove which system an event came from. access-consumer subscribes to every system's audit topic and takes the system from the subscription, refusing to the dead letter an event that claims another system.

Who acted, as whom, on what (decided 2026-11-11): GET /events filters by organization, the Organization the action concerns (the subject, such as a farm), and by acting_organization, the Organization the user acted as, so the Console finds what an insurer or a cooperative did on the farms that delegated to it. An action of the job access-bootstrap-admin has no actor: actor_system is access-bootstrap-admin and after names the operator who ran it, which is what the Console shows for a staff membership with no assigner.

5.4.2.3.2 Operations¶

Every operation names who calls it and the capability it checks (x-moonitoring-audience, x-moonitoring-capability in the contract); every capability is in the catalog of the data model (req 1002, 1006). Lists are paged by cursor, writes that create something carry an Idempotency-Key, errors are Problem Details.

5.4.2.3.3 Contract v1¶