SystemLOG and Ticker: Making RABS Speak More Clearly

The SystemLOG and ticker sweep is still in progress, but it is far enough along to explain why it matters. RABS already has the core notification path: emitEntry() writes to syslog.entries, the interpreter turns important events into notifications, and the admin frontend can surface those through the bell, tiles, toasts, sounds, and SSE.

The next step is getting more meaningful events into that path.

That sounds ordinary, but it is one of the differences between an admin system that stores work and an admin system that keeps people current.

The ticker is the broad announcement layer. It is for things users of Admin should know without having to hunt for them: policy publication, maintenance status, blog/news updates, lunch lifecycle events, and other global or near-global changes. It is not supposed to replace targeted notifications, and it is not supposed to become an audit log. Its job is to keep the visible surface of Admin alive with relevant current information.

SystemLOG is the auditable event stream. It is where important changes should be recorded with enough structure to answer the later question: what happened, who triggered it, what entity was affected, and what category of work was it?

Why More Data Matters

Right now, too many important actions can happen quietly. The feature may work, the row may update, and the user may see a local success message, but the wider system does not always receive a useful event. That limits notifications, dashboards, operational awareness, and later forensic review.

The current sweep is about closing those gaps without making noise. The mission separates broad ticker events from targeted or auditable syslog events. It also avoids dumping sensitive values into messages; details belong in structured context where they can be controlled and interpreted.

Ticker Work

The ticker foundation is being hardened around clearer taxonomy, metadata, source fields, display filtering, and safer acknowledgement behavior. Blog publishing is also being wired so a devLOG post announced to Discord can create a matching ticker entry inside Admin.

That creates a useful loop: publish news once, and Admin users can also see it in the place they already work.

The settings side is planned as display control, not event suppression. Turning off a category in the UI should not stop the system from recording the event. It should only decide whether that category is displayed in that surface.

SystemLOG Work

The syslog sweep is targeting high-confidence operational areas first: HR contracts, policies, staff lifecycle, participant lifecycle, documents, finance, rates, and payroll-sensitive paths. The medium-confidence areas are being classified before emission so the log does not become a stream of low-value noise.

That classification step is important. RABS needs more visibility, but not every internal loop deserves a notification or audit entry.

OpsLOG Is Next

OpsLOG is still deferred because the engine build is right around the corner. That is the correct order. SystemLOG and ticker keep the current admin surface aware. OpsLOG should become the main operational engine layer once the deeper engine work lands.

This sweep is the preparation layer: make current events visible, make useful changes traceable, and keep the admin team informed while the larger operational engine comes into view.