#Events with Provenance

Operational systems usually split “what ran” from “what changed.” Logs, task trackers, workflow records, webhook deliveries, and audit trails all end up in different places. WWKG keeps the split where it matters, but connects the records.

A Task shows work in progress: who started it, where it ran, what phase it reached, and whether it failed. An Event records the domain-level fact that the work produced: a member was invited, a branch was merged, an ontology was released, a lead was qualified, an email was delivered, or a state transition succeeded.

#Queryable events, not side logs

WWKG stores workspace events as graph data in the workspace event graph, urn:wwkg:graph:events. They are encrypted with the workspace, replicated with the workspace, and queryable through the same graph infrastructure as the rest of your knowledge.

Events use the public wwkg: ontology, not hidden sys: vocabulary. That means event history is part of the data model:

• wwkg:Event identifies the event resource.
• wwkg:eventKind identifies the system, domain, or business event type.
• wwkg:eventCommit links the event to the commit that contains or produced it.
• wwkg:eventTask links the event to the task that directly generated it, when that task is known.
• wwkg:eventActor records the person, agent, service, or pipeline that caused the event.
• wwkg:eventCausedBy links derived events back to source events.

#PROV-O compatible by design

WWKG maps events to PROV-O so provenance tools can understand the shape of the record:

The event is the entity that happened in the workspace. The task is the activity that did the work. The actor is the agent responsible for the action. The commit anchors the event in branch history.

#Why the task link is not enough

The canonical durable chain still goes through commits:

That matters because commits are part of workspace history. Tasks are operational execution records with their own retention and projection rules. WWKG also records the direct wwkg:eventTask link for ergonomics, so a query can jump straight from a domain event to the work that produced it:

Together, those links let you answer both kinds of question:

• “What changed in this workspace?”
• “Which task, actor, branch, and commit produced that change?”

#State transitions become events

State management uses the same event model. A successful transition such as crm:LeadQualified, sm:OntologyReleased, or cb:UseCaseDeployed writes a state assertion and a state:TransitionEvent into the workspace event graph. That event can trigger business events, workflow continuation, notifications, webhooks, or release automation after the commit.

Failed transition attempts are different. They belong in task, validation, or approval records unless the workspace explicitly defines a separate failure-event kind. WWKG does not confuse a failed attempt with a successful state transition.

#What this enables

• Audit trails that are data. Events are graph resources, not external log lines.
• Agent accountability. Agent work can be traced from event to commit to task to actor.
• Workflow automation. State transitions and domain events can drive follow-up tasks, approvals, webhooks, and notifications.
• Cross-domain history. CRM, Semantic Modelling, Email, Composable Business, and future apps can all use the same event structure while keeping their domain-specific event kinds.
• Derived business events. Higher-level events can cite their source events through wwkg:eventCausedBy.

#Next steps

Related features: Activity Monitoring, Branching and Merge Workflows, Reasoning and Validation, and Data Validation.