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/Release notes/Roadmap

Roadmap

What we will build next. No dates, and none of it is shipped.

Everything on this page is written in future tense on purpose. If something here reads as though it already works, that is a defect in the page and we want to know. Anything that is shipped lives on a platform page in present tense, where you can ask us to demonstrate it.

How this list is ordered
the ruleA capability ships when the evidence for it can be produced — not when the feature demos well.
tenseFuture, throughout. Nothing on this page is a description of the product today.
datesNone. An order we can defend is worth more than a date we cannot keep.
shipped workMoves off this page and onto a platform page, in present tense.
how you find outA release note that names the version and the claim it moved.

The ordering rule

We build the proof path first, then the feature.

Most roadmaps are ordered by what is easiest to demonstrate. That is how an industry ends up with automation nobody can audit. Ours is ordered by one question asked of every candidate, and a great deal of work has been deferred by the answer.

How a candidate gets onto this pageone question
HOW WE DECIDE WHAT COMES FIRST A candidate Something you asked for, or something we want to build. The one question Can the machine that was changed prove the change? YES Then it can ship. It goes on this page, and then into a dated release note. NO Then it waits. And the next piece of work is the proof path, not the feature. THE EVIDENCE PATH BECOMES THE WORK
The loop is the honest part. A capability that fails the question does not get shelved — it gets re-scoped, and the next thing built is whatever would let a target machine answer for it. That is why some obvious features are further down this page than you would expect.

Now

What we are working on.

  • NOW

    Open the public release log

    Every release will be dated, named, tied to the claim it moves, and paired with what had to be proven before it shipped. It will open at general availability, and the first entry will genuinely be the first. The shape it will take →

  • NOW

    Widen certified-runbook coverage

    We intend to keep certifying fixes for the ticket types that actually fill an MSP's queue, so the planner selects a proven runbook more often and has to plan from scratch less often. Coverage is the slow, unglamorous work that decides whether any of this is useful on a Tuesday.

  • NOW

    Put software inventory in front of a technician

    What is installed on a machine should be something a person can read, filter and act on — and something a plan can read as a precondition before it proposes an install or a removal.

  • NOW

    Make the standing-privilege audit a workflow you run

    Reading a directory for admin and elevated accounts is the identity half of onboarding, and it is the artifact an insurer asks for. We intend to make it something an operator runs, acts on, and exports — not a report that names a problem nobody can fix from the same screen.

Next

What we intend to start after that.

  • NEXT

    Broaden the ways a person can ask, and answer

    More of the places people already ask for help, and approval from a phone — so a technician does not have to be at a desk to say yes to eight minutes of admin rights.

  • NEXT

    Assemble more of the quarterly pack for you

    Deeper reporting, with each figure labelled by where it came from, so a client review is something you review rather than something you build. Reporting today →

  • NEXT

    Widen what a governed session records — one surface at a time

    We intend to extend session evidence surface by surface, and to describe each addition precisely as it lands. We will not describe it as complete recording and playback until every surface has been demonstrated end to end, and we would rather be slow here than be believed and wrong. What is covered today →

  • NEXT

    Let the model endpoint be yours

    Customer-hosted inference, for organisations whose policy requires it. The destination of the reasoning changes; the boundary does not — the model still never receives a credential value.

  • NEXT

    Complete a third-party audit and publish the report

    SOC 2 Type II is on the roadmap and we say where we stand plainly. We will publish the report when there is a report, rather than a letter saying an engagement has started — and in the meantime every operation produces the evidence such a report samples.

Later

What we believe comes after, and why it is not sooner.

  • LATER

    Learn from the operations that went wrong

    A model of how this system fails — abandoned plans, wrong selections, verifications that never landed — built from real operations. It sits here rather than in "next" because a knowledge base built before you understand your own failure modes just remembers them faster.

  • LATER

    Reach further into the systems you already run

    Deeper connections into the ticketing and billing tools an MSP lives in. Named vendor integrations are a conversation to have on a demo, not a claim to make on a roadmap page.

  • LATER

    More autonomy settings, with nothing loosened about proof

    Further along the dial, what changes is when a human authorizes — never whether the work is leased, blind, verified and recorded. We will not ship a setting where nobody's name is on the work. Commanded autonomy →

  • LATER

    Evidence that spans more than one operation

    A programme view: standing privilege coming down month over month, coverage widening, exceptions shrinking. The people who have to report upward need a shape, not a pile of receipts.

The rules of this page

What a roadmap will never be used for here.

  • Closing a deal. "That is on the roadmap" is not a feature, and we will not let it act like one in a sales call.
  • Carrying a date. We would have to guess, you would plan against the guess, and one of us would be wrong in public.
  • Listing something already shipped. Shipped work moves to a platform page in present tense so you can ask us to prove it.
  • Listing something we cannot describe the evidence for. If we cannot say how a target would confirm it, it is not ready to be a plan.
  • Changing quietly. When something leaves this page, a release note says where it went — including when the answer is that we dropped it.

If your business depends on one of these landing in a particular order, tell us. Discuss the required scope in a workflow conversation before purchase.

Judge the shipped part

The roadmap is intent. The demo is the product.

Fifteen minutes to inspect one supported operation and the correlated record it produces. Recovery is reviewed when the runbook provides it. Everything you see on that call is shipped, and everything on this page is not.