OpsChain 5.6.1: The First GA Release, by Invitation

OpsChain 5.6.1 is the first release we call generally available. Everything before it was an internal cut: the platform ran our own estates, our own labs and the capability suites that walk every release, and each of those cuts found something we were not willing to ship. This one did too, and we fixed it before the tag. That is the point of the process, and we will write about it separately.

Access is by invitation. We onboard deliberately, because OpsChain runs real changes on real estates. This post says what is in the release, who it is for, and how to ask.

What a governed operations platform is

OpsChain is one control plane for operational change. You describe your estate as a tree of projects, environments and assets. You describe work as actions and workflows, in YAML your repository commits. The platform then governs the execution: who may run what, which approvals must hold, which window applies, which secrets are resolved and masked, and what evidence is written. Every run lands in a hash-chained, tamper-evident audit lane, in the vocabulary your frameworks use.

The release brings that posture to five areas.

1. Change governance that is enforced, not hoped for

Approval policy is bound to the estate path, not written into the runbook. Quorum is enforced, self-approval is excluded by the platform, change windows apply, and overrides are explicit, permission-checked and audited. New in this release:

• The approver sees why. Every held change carries its approval context: the requester and their stated rationale, the recommendation it implements when an agent raised it, and the correlation chain from the incident or request that started the work to the change in front of you.
• Decision history. An approver can see what they approved before; a governance administrator can see every decision.
• Why a step failed reaches you. A refused or failed step shows its reason on the step itself, in the GUI and the CLI, not only in a server log.

2. Security governance you can evidence

Path-based RBAC with explicit authorisation on every request. OIDC and LDAP identity providers beside local accounts, with step-up authentication for sensitive operations. Vault custody of secrets: built-in, or yours, never inlined into automation. In 5.6.1 the audit trail also records where each action came from: the proxy-aware client address, the user agent and the acting credential on every audited event and session, with a stated retention posture.

3. AI operators, supervised by default

An AI operator in OpsChain is a governed teammate: a named human owner, a trust tier (Advisory, Supervised, Autonomous) earned on recorded evidence, server-side transcripts with redaction, action-count budgets, and a kill switch that is one operator, a group or everything. This release adds the release discipline operators need at scale: one agent runs as many instances across lanes; a new release rolls out blue-green with a canary, held in the same approval funnel as any other change; and an instance logs every platform-driven state change that happens to it, so the record is the agent's own.

4. Signed content packs: cloud and identity under approval

Three content packs ship beside the platform, each a signed bundle gated by its own entitlement:

• AWS (packs:aws): the operation surface of ten AWS services as governed, native actions, with waiters, so a CloudFormation deployment, an RDS change or an IAM edit runs under your approval policy and lands in your evidence.
• Azure (packs:azure): the ARM management surface as native actions, generated and typed, plus deployments, virtual-machine commands, images and Key Vault, with progress reported every thirty seconds on long operations.
• PingOne Advanced Identity Cloud (packs:ping-aic): a tenant's configuration as YAML your repository commits, reconciled by plan, apply and export, and the tenant operations a change composes as typed actions.

Every pack step installs its own tool when the runner it lands on lacks it, so a fleet of runners needs no shared cache and no host affinity.

5. The Academy and the learning path

opschain learn is now a curriculum: 76 lessons in 15 capability modules, six role tracks (Foundations, Author, Operator, Admin, Governance, Agent builder), one manifest. Every lesson states one testable outcome and its prerequisites as a checklist, and its duration is computed from reading plus doing, measured where an exercise exists. The Foundations track fits an evaluator's hour. The Academy agent, launched with opschain academy, tutors against your own estate with a model provider from your catalog; packs:academy is in the Basic tier with Foundations included.

How it reaches you

The binary is signed and verifiable on every platform: Developer ID and notarisation on macOS, Authenticode on Windows, and a cosign-sealed SHA256SUMS.txt under a pinned release key for every archive. Homebrew and Scoop carry it; Linux has the archives and an installer that verifies the digest before it extracts anything. When you receive access, the Install page shows every fingerprint and digest, none typed by hand.

Who it is for

Regulated enterprises that run change across cloud, identity and on-premises estates and must evidence it: banking and financial services under CPS 230 and CPS 234, critical infrastructure under SOCI, telecommunications under TSSR, and any operations team that wants AI operators on BAU work without giving up the controls a risk committee asks for.

Request access

Access to OpsChain is by invitation only. Tell us who you are and what you would like to run, and we will be in touch: request access. If you would rather see it first, book a demo and bring the estate you have in mind.

---

Key takeaway

5.6.1 is the first release we stand behind for your estate: governed change and security governance with evidence, AI operators under platform controls, signed content packs for AWS, Azure and PingOne, a curriculum to learn it in an hour, and a distribution you can verify before you run it.