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.

Operational logs are part of the control surface. In a single-node demo it is tempting to let the same process receive logs, write the search index, and serve the viewer. That works until the Control Plane itself needs to scale, restart independently, or run without holding the only Lucene write lock.

jPOS now splits that responsibility into a dedicated log ingestion path: workloads emit structured jPOS JSONL logs to standard output, Fluent Bit transports labelled pod logs, a log-ingestor service owns the write side, and the jPOS Control Plane reads the shared index read-only.

The best jPOS version is usually the latest one.

That may sound counterintuitive if your organization treats -SNAPSHOT as a synonym for "unstable", but that is not how we operate jPOS and jPOS-EE. We work hard to keep the latest snapshots production-ready. We run them in production ourselves. They are where the current fixes, optimizations, dependency updates, security improvements, and newly certified behavior land first.

In practice, the latest snapshot is often the most advanced, optimized, and feature-rich jPOS version available.

jPOS 3 introduced structured audit logging as a first-class feature: instead of writing only text lines, a log event can carry typed payloads such as start, stop, deploy, connect, disconnect, txn, and so on.

That structure is what makes tools such as the jPOS Log Viewer possible. The viewer can filter, facet, correlate, and render events because it is not guessing meaning from text. It is reading fields.

Until now, however, those typed audit events were effectively limited to the event classes shipped inside jPOS itself. That was fine for core runtime events, but it was not enough for real applications.

A jPOS-EE module, an application module, or a customer-specific extension may have its own operational event worth logging in a structured way:

• an HTTP access event from QRest,
• an authentication event from a web application,
• a business workflow transition,
• a settlement file import,
• a reconciliation result,
• a domain-specific warning that deserves first-class fields.

Those should not have to be flattened into strings. They should be allowed to live next to the built-in jPOS audit events.

That is now possible.

Deploying financial infrastructure should not depend on someone remembering the right kubectl context, pasting the right kubeconfig into the right terminal, or manually reconstructing which Helm values were used last time. The deployment path is part of the control surface. It needs the same auditability, separation, and repeatability as the ledger itself.

The jPOS Control Plane brings Kubernetes deployment into the operator console. It stores target cluster credentials encrypted at rest, registers Helm charts from OCI registries, turns JSON Schema-backed chart values into typed forms, binds everything into reusable release plans, and drives dry-run, preflight, apply, resources, and logs from one audited UI.

The jPOS Common Message Format specification is getting an update. CMF v3 is still a work in progress, but an early-access draft is available at jpos.org/doc/jPOS-CMFv3.pdf for anyone who wants to follow along. The most significant addition in v3 is first-class support for the ISO 8583 dataset model—and that's what this post is about.

Every ledger has a set of transactions it posts over and over. The accounts change, the amounts change, sometimes the counterparty changes—but the structure is always the same. A fee charge is always a debit to the customer account and a credit to fee income. A settlement is always the same four entries. A foreign exchange conversion follows the same arithmetic every time.

Freeform posting can handle all of these, but it puts the entire burden of correctness on the operator: right accounts, right sides, right layer, right formula—every time, by hand. Templates solve this. A template captures the invariant structure of a transaction and exposes only the parts that actually vary. Everything else is handled by the ledger.

Most ledger enforcement is hardcoded. If the business needs a new limit—a maximum account balance, a cap on transaction size, a rule that blocks weekend postings—someone files a ticket, a developer writes a check, the code ships in the next release. That cycle takes days or weeks, and the logic lives in application code rather than in the ledger where it belongs.

MGL solves this with Dynamic Rules. A dynamic rule is a CEL expression that the system evaluates on every posting, in real time, before the transaction is committed. If the expression returns false, the transaction is denied. No code change required. No deployment.

Most accounting systems that want to show derived figures—variance against budget, percentage execution, a consolidated multi-currency total—end up solving the problem the same way: periodic batch jobs that write synthetic entries to hold the computed values, or reporting scripts that reconstruct the computation at query time outside the ledger.

Both approaches have the same flaw. The derived figures live in a different place than the authoritative entries. They get stale. They diverge. Reconciling them back to source is always someone's problem.

MGL solves this with virtual layers. A virtual layer carries a formula instead of entries. Its balance is computed on the fly from physical layers—always derived from the same source of truth, always accurate to the query date, with no batch job required.

Since ISO 8583:2003, the standard has defined three types of data elements: primitive, constructed, and composite. Primitive and constructed fields have always had first-class support in jPOS. The third type—composite fields—has historically been treated as opaque binary blobs, with application code responsible for parsing their contents manually.

jPOS 3.0.2 changes that.