In Latest and Greatest, we recommended a simple rule: use the latest -SNAPSHOT while developing, then pin the exact timestamped build that passed QA before deploying it.

The rule is simple. The manual version was not.

Someone had to find Maven metadata, copy the timestamped version, edit gradle/libs.versions.toml, make sure every related library was considered, and later remember which value used to be a moving snapshot. That is precisely the kind of release step that should be boring and repeatable.

jPOS Gradle Plugin 0.0.19 adds three tasks for that job: pins, pin, and unpin.

Operators should not have to discover that something went wrong.

A failed job, a locked account, or an error during a release is useful only if it reaches the person who can act on it. The new jPOS Control Plane notifications demo shows that path end to end: from an operational event, through routing and delivery, to the operator’s inbox and the channels the team already watches.

Reading a payment transaction is still expert work.

An authorization is not just an amount and a response code. It is the incoming ISO 8583 message, the authorization decision, the card and product state, the transaction chain around it, the ledger postings it produced, and the operational context that explains why it ended the way it did.

The new Transaction Log Inspector demo shows a practical way to make that expertise available on demand: explain a transaction in plain language, directly from the jPOS Control Plane, without turning the assistant into a side channel.

TransactionManager context contracts are a small feature with a large documentation payoff.

When a participant declares:

<requires>REQUEST</requires>
<provides>RESPONSE</provides>

the TransactionManager can do two useful things. First, it can abort early if a required input is missing. Second, when requires or optional is present, it can call the participant with a restricted clone of the Context and later merge back only the keys listed in provides.

That makes the TM configuration more than a list of Java classes. It becomes a readable contract for the transaction flow: this participant needs these inputs, may look at these optional values, and is expected to produce these outputs.

Payment systems are only as trustworthy as the testing behind them.

For an issuer, correctness is not just a response code. It is the ISO 8583 message on the wire, the product rules that shaped the decision, the ledger entries that were posted, and the evidence an operator can inspect later.

The new Client Simulator demo shows that loop end to end on the jPOS Control Plane: a live jCard issuer, a real CMF channel, a functional test suite, raw logs, and a reconciled general ledger.

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.