PlatformDelivery BoardAutomation & RunbooksOutcome ReceiptsJust-in-Time ElevationCredential VaultGoverned SessionsDevices & DiscoveryPatch ManagementReporting & ExportsRoles & Multi-Tenancy
Verified AI OperationsThe Operation LoopCommanded AutonomyCompare the operating modelThe Verified Operation Spec
SolutionsFor MSPsFor Enterprise & Internal ITHealthcareLegalFinancial servicesMunicipal & Education
ProofOperation walkthroughSecurity & architectureVerified Operation SpecFive questions for your RMM's AIChangelog
CompanyAboutFounder's noteContact
PricingBuy 1–20 technician licenses onlinePlans — from $499 per monthCustom requirementsFoundation Circle
Log in

Home/Proof/Release notes

Release notes

No entries yet. Here is exactly what will be in them.

We could have filled this page with nine dated entries you would have no way to check. On a product sold on evidence, that is the one thing we cannot do. So this page is the log's shape, the gate a change has to pass before it reaches your workspace, and a straight answer about when the first entry lands.

  • CURRENT

    Nothing published yet

    The public log opens at general availability. Until then the honest answer is that there is nothing here to read, and we would rather you saw an empty page than a convincing one.

  • EVERY ENTRY, ONCE IT OPENS

    vX.Y · dated · beta ring first

    What changed · what it means for you · which claim on this site it moves · and what had to be proven on a live system before it shipped.

  • AND WHEN WE GET SOMETHING WRONG

    The correction, in the same log

    A fix that follows a defect names the defect. A release log that only ever carries good news is a marketing feed with version numbers on it.

Release discipline

How a change actually reaches your workspace.

Until there are entries, the useful subject of this page is the process that produces them. There is one gate, it is deliberately annoying, and it is the reason we would rather ship slowly than describe something as working before it is.

From a commit to your workspacethe gate is the whole point
FROM A COMMIT TO YOUR WORKSPACE A change Built against real storage, not a stand-in. The gate It has to be shown working on the surface you use. The ring Published to the beta ring, signed, with a version. Your workspace Components converge and report the version they are running. FAILS THE GATE → BACK TO THE BENCH, NOT INTO A RING THEN, AND ONLY THEN, THE RELEASE NOTE It describes what shipped and what it means for you — written after delivery, never as an announcement of intent.
The gate does not accept unit tests. It accepts a live run on the surface a human actually uses, against real storage. A green test suite has told us a feature worked while the deployed product could not do it at all — which is why the gate is drawn where it is.
  • Everything ships to the beta ring first. A ring is a delivery audience, not a quality label — the ring decides who gets it, the gate decides whether it is fit to send.
  • Components report their own version. Convergence is push-driven, and a workspace can be asked what version each component is actually running rather than what it was told to run.
  • A change that spans surfaces ships as one. Shipping the back end and forgetting the screen is the most common way a release note becomes untrue.
  • The note is written last. It records what landed, so it can name the version you can check for yourself.

The shape of an entry

Five things, every time, in the same order.

Most release notes are written for the vendor. These are written for the person who has to explain a change to a client on Monday morning.

  1. Version and date

    The version string you can compare against what your workspace reports it is running, and the date it reached the ring. Not the date the work started.

  2. What changed

    In specific nouns. "Certified runbook coverage for print-queue recovery on Windows Server" — not "various improvements to automation".

  3. What it means for you

    Whether you have to do anything, whether a policy default moved, and what a technician will notice on screen. If the answer is "nothing", it says nothing.

  4. Which claim on this site it moves

    If a release turns something on the roadmap into something on a platform page, the entry names both. That is how you audit whether the marketing kept pace with the product — or ran ahead of it.

  5. What had to be proven before it shipped

    The live check that opened the gate, in one line. Every entry inherits the same standard as the product: an assertion nobody demonstrated is not a result.

The rules of this log

What will never appear on this page.

  • Backdated entries. The log opens at general availability and starts on that day. We will not reconstruct a plausible history for the months before it.
  • "Various improvements and bug fixes." If we cannot say what changed, the entry is not finished.
  • A silent change to a shipped claim. If something described on this site stops being true, the entry says so in the same words the page used.
  • Marketing entries. A new page, a new logo, or a conference is not a release. This log is for things that changed in your workspace.
  • Anything we cannot show you. If it cannot be demonstrated on a live system, it did not pass the gate and it has no entry.

This is the same standard the rest of the site is held to, and it is the reason the certification section opens by telling you we hold none. A release log is only worth reading if the absence of an entry means something.

An empty log is a claim too

Judge us on the running system, not on a page of entries.

Bring the hardest question from your last client audit. We will answer it on the call, against a live workspace, rather than pointing at a version number.