The code is nearly ready. The operations are not.

The observability stack is a single dependency, spring-boot-starter-actuator, and three exposed endpoints. There is no metrics registry, so /actuator/metrics has nothing scraping it. There is no tracing library. There are no correlation identifiers anywhere — a search for MDC, traceId, correlationId and requestId across the whole backend returns nothing, so the 123 log statements cannot be tied to a request, a tenant, or each other. There is no logging configuration file, so output is Spring's default console pattern rather than structured JSON.

There are also no custom health indicators. Health is the framework default, which checks the database and nothing else — not Keycloak, not Accountly, not Kill Bill, not the KMS provider, not the blockchain anchors. Every one of those can fail while the load balancer still sees a healthy instance.

There is no infrastructure-as-code of any kind — no Terraform, no CDK, no Kubernetes manifests, no CloudFormation. The only deployment artifact is docker-compose.yml, and DEPLOYMENT.md presents it as the recommended path. That file hardcodes POSTGRES_PASSWORD: postgres, KEYCLOAK_ADMIN_PASSWORD: admin, DATABASE_PASSWORD: postgres and an empty KEYCLOAK_CLIENT_SECRET.

This is the same class of defect that SA-R10-06 and SA-R11-02 fixed inside application.yml. Those fixes made the application refuse to start without real credentials; the deployment file then supplies the weak ones from outside, which puts the default back.

Eight dependencies resolve to com.geoknoesis.trustweave:*:1.0.0-SNAPSHOT, including trustweave-all, the KMS providers and the status-list implementations. A SNAPSHOT is mutable by definition: the same build, run twice, can produce different binaries. That removes reproducibility, auditability and the ability to roll back to a known artifact — which for a service whose product is verifiable trust is a particularly awkward place to be. The coordinate also names a version, 1.0.0, that the library has never released; the library is at 0.7.0.

The mitigation in place is genuinely clever and worth keeping: CI pins the library by git revision and verifies a source hash before building. But that guarantees the inputs were reviewed, not that the resolved artifact is immutable or reproducible from a coordinate.

Two mechanisms assume a single process. The rate limiter is an in-process HashMap behind a single @Synchronized lock, so the effective limit multiplies by instance count — and it is the only control protecting the public verification and claim endpoints. Five of the six @Scheduled jobs have no coordination at all; only the OID4VP verification path takes a database work lease.

The usage-outbox drain is the one to look at first. It selects PENDING and FAILED rows with a plain derived query — no SKIP LOCKED, no pessimistic lock, no claim before the HTTP call — so two instances would post the same usage events concurrently. Each event does carry an idempotency key, so billing correctness rests on Accountly honouring it rather than on anything local. That is a reasonable belt, but there is no braces.

The round-11 remediation pass reports that Docker stalled during PostgreSQL container startup and the test worker was killed after five minutes, leaving the integration tests compiled but unverified — and notes that prior full-backend instability has not been cleared. That matters more than usual here, because the strongest recent addition, FlywayMigrationTest, is a Testcontainers test. The check that proves the schema builds from empty is exactly the check that currently cannot run.

To the team's credit this was reported plainly rather than papered over, and the remediation explicitly declined to self-score because of it. But a green pipeline you cannot reproduce locally is not a signal you can deploy on.

The library publishes to Maven with no GPG signature, no SBOM and no build attestation, and CI runs no SAST. Carried forward unchanged from round 10, but it reads differently under a readiness rubric: this is a security library whose entire proposition is that recipients can verify provenance, distributed by a channel that offers its own recipients none. Signing is required for Maven Central regardless, so it has to happen before any real release anyway.