Event bus
Objective. Understand the event bus as an internal platform mechanism - how applications stay in step - at a conceptual level only, so you can explain the customer-visible benefit (things connect and flow) without asserting internal architecture you cannot verify.
The event bus is an internal plumbing concept, not a customer-facing feature. This short module gives Sales and CSM the one honest, benefit-level thing to say and a firm instruction to escalate any architectural question - because this is a topic where it is easy to sound technical and be wrong.
See it in the demo
What the event bus is in Time Champ terms
An event bus is internal plumbing: a mechanism by which something happening in one place is communicated so other parts of the platform can react. In customer-visible terms, it is part of why the applications behave as a connected platform rather than twelve disconnected tools - a schedule is published and adherence can compare against it, an action is taken and the action log reflects it, a finding moves from open to verified.
Crucially, the event bus is an implementation detail. It is not a screen, not a demo surface, and not something a customer buys or configures. For Sales and CSM, the only useful idea is the OUTCOME it enables - the platform is integrated and things flow between applications - not the mechanism itself, which you have no basis to describe in detail.
What a Sales or CSM person can say confidently
Safe to say, at benefit level only: 'The applications work as one connected platform - what happens in one, like publishing a schedule or recording an action, flows through to the others that need it.' That is a true, customer-relevant statement about behaviour.
Safe to redirect: if a technical buyer wants architecture, say 'I will bring in our specialist to walk through the platform architecture properly.' That is the credible move, not an improvised description of messaging internals.
Do not describe the event bus technology, its delivery guarantees, ordering, latency, or any internal design. You will not have verified it, and a technical listener will catch an approximate claim immediately. This is a topic to stay OUT of at any specific level.
What always escalates to security or product
Route to a specialist (architecture/product):
- Any question about the event or messaging technology, its guarantees (delivery, ordering, replay), latency or throughput.
- How real-time the cross-application flow is for a specific scenario.
- Whether the event stream is exposed to customers or integrations (if a customer wants to consume events, that is a PLAT-08 integration-and-API question for a specialist).
- Any resilience, failure-handling or data-consistency question.
The posture: the event bus is internal. Benefit-level statements are safe; anything mechanism-level escalates without exception.
The honest limit
Platform-true at benefit level: the applications behave as a connected platform and relevant changes flow between them (visible as, for example, schedule publication feeding adherence, and actions feeding the action log).
Confirm with product/architecture: the event or messaging technology and all of its characteristics, how real-time any specific flow is, event exposure to integrations, and resilience behaviour.
Separate cleanly: 'the applications are connected and changes flow between them' (safe, behaviour-level) from any statement about the underlying event or messaging architecture (always a specialist). When in doubt on this topic, say less.
Interpretation check
The event bus is internal plumbing, not a feature; the only safe statement is the customer-visible outcome (the platform is connected and changes flow between applications). Any mechanism-level claim about the event or messaging technology is a specialist topic.
Practical task
Write the single benefit-level sentence you would use to explain why Time Champ behaves as one connected platform, citing one concrete cross-application flow from the demos (for example schedule publication feeding adherence). Then write the one-line redirect you would use when a technical buyer asks about the architecture.
Self-check
A customer asks how the applications stay in step. What is the safe, benefit-level answer?
The applications work as one connected platform, so a change in one - like publishing a schedule or recording an action - flows through to the others that need it, without describing the internal mechanism.
A technical buyer asks about delivery guarantees and latency of the event bus. What do you do?
Route it to an architecture/product specialist; delivery, ordering, latency and resilience are mechanism-level facts you never improvise.
A customer wants to consume the event stream in their own systems. Where does that go?
That is an integration-and-API question (PLAT-08) for a specialist - whether and how events are exposed is not a benefit-level claim you can make.
Why is this a topic to stay out of at any specific level?
The event bus is internal and not demo-visible, so any detailed claim is unverified and a technical listener will catch it - benefit-level statements are safe, mechanism-level claims escalate.
Verified vs demo. That the applications behave as a connected platform with changes flowing between them is observable in the demos at behaviour level; the event or messaging technology, its guarantees, latency, event exposure and resilience are product/architecture facts to confirm.