Attributable actions
Actor, tenant, action, resource, and request context travel together in one event.
Product history and investigations
Make every important product action explainable.
Audit Log records who did what, to which resource, inside which tenant, and what changed—so support, operations, and security teams can investigate from structured product history.
Inspect the published API contractAudit Log domain
Structured event investigation
Operational workspace
From a customer question to the exact action and change.
Role changed
Actor, tenant, resource, and action captured together
Change set attached
Previous and new values retained as structured context
Tenant filter applied
Investigation remains inside the customer boundary
History inspected
Support or security reviews the attributable timeline
Actor contextTenant boundaryStructured changes
- Lifecycle
- Available
- Interfaces
- REST · Connect/gRPC · MCP via Agent Gateway
- AWS path
- Design-partner pilot
- Commercial basis
- Perpetual source license
Product outcome
Application logs tell engineers what ran. Product audit history tells the business what happened.
Important account, access, and workflow changes need durable actor and resource context. Audit Log gives those events a queryable domain model instead of leaving investigators to reconstruct business actions from infrastructure logs.
Readable changes
Structured before-and-after values make consequential updates easier to understand.
Faster investigations
Operations can filter product history without beginning every question in raw service logs.
01 / Domain capabilities
A complete Audit Log boundary, not a thin endpoint wrapper.
Each capability belongs to the same tenant-aware service contract and can be adapted in the licensed source.
01
Structured event ingestion
Record business actions with explicit actor, tenant, action, resource, request, and metadata fields.
02
Actor and resource context
Keep the person or system responsible for an action tied to the product object that changed.
03
Before-and-after changes
Attach structured change sets so reviewers can see what moved without comparing opaque payloads.
04
Queryable tenant history
Filter events by tenant, actor, action, resource, and time through a documented cursor-based interface.
02 / Product workflow
One path from product intent to an enforceable result.
The overview stays business-readable. The documentation and published contract contain field-level detail.
- 01
Describe the action
The producing service identifies the business action, actor, tenant, resource, and relevant request context.
- 02
Record structured change
Audit Log accepts the event and any before-and-after fields through its published contract.
- 03
Retain tenant history
The event becomes part of the chronological product trail for the customer boundary.
- 04
Query and investigate
Authorized operational workflows filter and inspect the event history when a question arises.
03 / Technical depth
Clear operational boundaries for the team that owns it.
Support is 12 months of updates and support. Deployment, updates, and customer-cloud responsibilities are reviewed before purchase.
Record a product actionHTTP / JSON
POST /audit.v1.AuditService/RecordEvent
Authorization: Bearer $TOKEN
Content-Type: application/json
{
"tenant_id": "company_72",
"action": "ROLE_UPDATED",
"actor": { "type": "USER", "id": "user_19" },
"resource": { "type": "MEMBERSHIP", "id": "member_44" },
"changeset": {
"changed_fields": ["role"]
}
}Durable event store
Structured audit records remain separate from transient application and infrastructure logs.
Service event boundary
Identity, Authz, Notifications, and product services can publish relevant domain actions.
Investigation interface
Cursor-based queries support operational timelines, filters, and resource-level history.
04 / Where it fits
Audit Log supports products with real tenant and commercial complexity.
These are product patterns, not customer case studies or measured outcomes.
Access investigations
Review role, membership, and authorization changes with the actor and changed resource attached.
Customer support history
Give authorized operators an attributable timeline when a customer asks who changed a setting or workflow.
Security-review evidence
Use structured product history as one input to your own security and compliance program; no certification is implied.
Ownership model
Own the service without owning every release problem.
The source license, update term, support boundary, and customer-cloud responsibilities remain explicit. Missing domain work can be scoped as a custom module instead of hidden in a roadmap promise.
01
Licensed Go source for the audit-history domain
02
Published REST and Connect/gRPC contract
03
Customer-controlled event data and retention decisions
04
Optional event types and investigation views scoped as custom work
Published API evidence active
Customer-cloud deployment path
Depends on identity
Audit Log architecture review
Put Audit Log behind a product boundary your team can own.
Bring the tenant model, workflow requirements, cloud target, and any missing module. We will map the service, its dependencies, and the delivery path before discussing a license.
Frequently Asked Questions
Common Questions & Answers
Everything you need to know about integrating and hosting this Launch Rail service.