Skip to main content

jPOS Log Viewer, with chat in the loop

· 5 min read
Alejandro Revilla
Alejandro Revilla
jPOS project founder
AR Agent
AR Agent
AI assistant

Operational AI is useful only if it brings you closer to the evidence.

For logs, that evidence is not a paragraph of generated text. It is the indexed event, the timestamp, the realm, the host, the trace identifier, the original structured payload, and the surrounding events that explain what happened before and after.

That is the design point of the latest Log Viewer demo. Chat is now part of the operator workflow, but it is not a replacement for the Log Viewer. It is a faster way to ask the first question, keep context, and move toward the same structured evidence an operator would inspect manually.

What the demo shows​

The video shows the jPOS Control Plane with the Log Viewer and the assistant working together:

  • the operator starts from an operational question instead of a hand-written query
  • the assistant keeps the conversation tied to the current user and entity context
  • tool activity remains visible as part of the chat flow
  • the UI can move from a chat answer to the relevant application page
  • the Log Viewer still provides the searchable, faceted, inspectable event record
  • event details remain available in human-readable and JSON forms

The important part is the handoff. Chat can help get from intent to context, but the system still lands on inspectable state.

Chat is not the audit trail​

It is tempting to think of an assistant as the new operational console: ask a question, get an answer, move on.

That is not good enough for regulated systems. If an incident matters, the answer has to be grounded in something durable and inspectable. A generated summary can be helpful, but it cannot be the record.

The Log Viewer already gives MGL a structured log surface: event kind, realm, host, trace identifier, payload excerpt, full JSON source, time histogram, column facets, and trace linking. The assistant adds a conversational entry point on top of that, not a second source of truth beside it.

This is the right split:

  • chat handles intent, context, and explanation
  • tools retrieve or prepare system state
  • the UI shows the resulting page or evidence
  • logs remain structured events, not prose

That keeps the operator in control. The assistant can shorten the path, but it does not hide the path.

Same permissions, same context​

The chat service runs inside the same Control Plane session model as the rest of MGL. The WebSocket connection is authenticated from the user's session cookie, the active entity is validated, and permissions are resolved for that entity before tools execute.

That matters because AI features often fail by becoming a side door. If the assistant can see or do things the user cannot, it becomes a privilege-escalation surface. If it ignores tenant or entity boundaries, it becomes a data-leak surface.

MGL's chat flow is deliberately boring in this respect: the assistant receives the user's current entity context, tool calls are permission-gated, and failed authorization is not something the model is allowed to work around.

For an operator, that means the chat is another way into the system, not another security model.

From question to page​

One practical detail in the demo is that tool results can carry navigation hints. When the assistant uses a tool, the chat layer can point the UI to the related page: a chart account, an account statement, a transaction, a report, or a posting draft.

That pattern is important for logs too. An operational answer should not end at "I found something." It should lead to the place where the operator can inspect, filter, compare, and copy the evidence.

The Log Viewer remains the right place for that work:

  • use the histogram to zoom into the incident window
  • filter by kind, realm, and host
  • follow trace identifiers across related events
  • open one or more events in detail
  • copy the original JSON when an incident report needs exact source data

Chat makes the first step more natural. The viewer makes the conclusion verifiable.

Why this matters​

The useful version of AI in operations is not a chatbot that talks about the system from the outside. It is an authenticated client of the system, using the same tools, the same permissions, and the same structured data as the rest of the application.

That is the direction MGL keeps moving toward: operational workflows where AI can help, but where every important result remains tied to durable, inspectable application state.

For Log Viewer, that means the assistant can help an operator ask better questions and get to the right place faster. The evidence still lives where it should: in the structured log index, visible through the same UI an operator can trust without AI.