Observability and Audit
Worka needs more than logs.
Users need to see progress in the product. Operators need to see runtime state, failures, approvals, publication outcomes, and service health. Auditors need to understand who did what and when.
Those are related but different needs. Good observability makes all three possible without making people reverse-engineer the platform from raw events.
What you should be able to see
At a minimum, operators should be able to inspect:
- workspace activity and workflow state
- waiting approvals and their resolution
- Forge runs and their current phase
- pack release and attachment history
- service deployment and health state
- runtime errors from pack execution
- browser or device capability health where relevant
Those views should agree with each other. If the workspace says work is complete but the runtime says it is still blocked, you have a projection problem.
Audit trail expectations
An audit trail should let you answer:
- who initiated a change
- which workspace it belonged to
- which AI team member or pack acted
- which approvals were requested and how they were resolved
- what was published, attached, or made public
The goal is not endless retention of every detail. The goal is reconstructability.
What to monitor continuously
Monitor:
- realtime connectivity and sync failures
- stuck or retrying workflows
- failed pack invocations
- degraded or failed services
- publication failures
- approval backlogs
- device and local capability health if you rely on them
The earlier you see those patterns, the less often users will discover them before you do.
When to involve deeper logs
Product-facing state should explain most failures. Use raw runtime logs when you need:
- the exact error from a pack container
- broker-level request failure detail
- service health probe detail
- registry or publication transport detail
Logs are important, but they should be the second stop, not the first stop.