Book a demo Buy online
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
Book a demoBuy online

Home/Proof/Live screens

Real product surfaces

Explore the surfaces that connect the work.

These are surfaces from the operator console, not concept art. Inspect how the board, vault, lease, session, patch wave and export contribute to one operation, so the work, oversight and resulting evidence can be read together.

See them driven liveThe operation walkthrough
House rules for these captures
what they areFrames from the operator console. Cropped and masked, never redrawn.
what is maskedTenant ids, real hostnames, device ids, addresses, client names.
the data in themOur own environment. No customer's records appear on this site.
the namesDana, Marcus and SRV-ACCT-02 are illustrations, and always have been.
an empty frameMeans that capture is still being taken. We would rather show you nothing.

Why the set matters more than any one screen

Six surfaces write to it. Three read from it.

A screenshot tour is usually a feature list with pictures. The thing worth checking here is the direction of the arrows: whether each module keeps its own log, or whether they all contribute fields to a single object that can be exported as one thing.

How the console surfaces relate to one operationOP-000217
SURFACES THAT WRITE TO IT SURFACES THAT READ FROM IT Delivery board WRITES: THE AUTHORIZATION JIT elevation WRITES: THE LEASE AND ITS EXPIRY Credential vault WRITES: THE CHECKOUT AND RETURN Governed sessions WRITES: THE SESSION BINDING Patch waves WRITES: THE JOB AND THE CHECK Devices & discovery WRITES: THE TARGET, AT THAT TIME THE OPERATION RECORD OP-000217 authorized · Marcus R 09:40 privilege · leased 8 min job · restart-spooler, signed answer · SRV-ACCT-02 running undo · declared up front target · SRV-ACCT-02 at 09:40 CHAIN 9f3a…c47e Reporting & exports READS: THE WHOLE CHAIN Roles & tenancy DECIDES WHO MAY SEE IT Your client's pack CHECKABLE WITHOUT US NO MODULE KEEPS A PRIVATE HISTORY — WHICH IS WHY THE EXPORT IS ONE ARTIFACT, NOT SIX
The nine screens below map onto this picture one for one. The test to apply while you look at them is whether any surface could be removed without the record losing a field — if it could, it was a dashboard rather than a participant. The operation loop explains the order the fields arrive in.

How to read the frames

The colours mean the same thing on every screen.

One key, applied everywhere in the product and everywhere on this site. Learn it once and the screenshots below stop being decoration.

The reading key, applied to one operation viewOP-000217
SERAPH · OPERATION OP-000217 REQUESTED BY Dana K · Teams AUTHORIZED BY Marcus R · 09:40 ADMIN ACCESS leased 8 min · expired 09:47 TARGET SRV-ACCT-02 RAN restart-spooler · signed THE MACHINE SAID service running · queue clear UNDO declared before execution chain 9f3a…c47e 1 The reference number always stays Never masked. It is what you quote back to us, and what an export still resolves to months later. 2 Amber is always privilege, on a clock Every amber value in the product is a right that exists for a stated time. Admin access shown without a clock beside it would mean something different, so it never appears. 3 This hostname is invented SRV-ACCT-02 is our illustration. Real hostnames, device ids, addresses and tenant ids are masked out of every capture. 4 Green came from the machine Not a summary and not a status chip — the answer the target returned when it was asked again, after the change. THE SAME KEY APPLIES TO EVERY FRAME BELOW: VIOLET IS US, AMBER IS PRIVILEGE, GREEN CAME FROM THE TARGET
One consequence of the key is worth stating out loud. There is no colour for "the AI thinks it worked", because there is no field for it — the confirmation line can only ever carry what the target answered, and if the check did not run the line says that instead.
If a frame below is emptySome captures are still being taken, and a frame that has not been filled yet shows a label instead of a picture. We have left it that way on purpose rather than dropping in a mockup or a stock console image, which is the same reason the three-minute recording has not been published yet.

The work

Where operations are run, watched, and taken over.

These three are the day-to-day surfaces. A technician spends their time here; everything else is consulted rather than worked in.

The Seraph delivery board, showing operations moving from awaiting authorization through to completed with evidence

Delivery board

Look at what an operation card carries before anyone touches it: who asked, which machine, which procedure, and how much of the lease is left. That is the whole decision, on one card.

Delivery Board →
The Seraph patch management surface, showing baselines and a governed wave in progress

Patch waves

Look at what stands between one wave and the next. Patching here is a sequence of gates rather than a schedule, and a gate is a place where something has to be true before more machines are touched.

Patch Management →
The Seraph devices and discovery surface, listing enrolled agents alongside discovered network devices

Devices & discovery

Look at the split between machines with an agent and machines that were only discovered. That boundary is a real constraint on what can be done, not a smaller feature set, and we draw it explicitly.

Devices & Discovery →

The board is the surface that decides how many workstreams one technician can hold, so it is the one to be sceptical about in a demo. Ask to be shown an operation stopping safely and handing back to a person — that path is more informative than a clean run, and it is the one commanded autonomy is built around.

The privilege

Where rights are borrowed, and where they end.

These three exist so that the answer to "what account did that run as" is never a shrug. Each of them writes a field into the operation record rather than keeping a log of its own.

The Seraph credential vault, showing stored credential records with their checkout and rotation state

Credential vault

Look at the distinction between a record and its value. The record is what an operation refers to; the value is resolved elsewhere and never reaches the model. Rotation is a property of records we have been asked to manage.

Credential Vault →
The Seraph just-in-time elevation surface, listing active leases with their scope and expiry

Just-in-time elevation

Look at the expiry beside every grant. A lease is scoped to one operation on one target and ends on its clock, which is a different promise from ending when the work does.

Just-in-Time Elevation →
The Seraph governed sessions surface, showing remote sessions bound to their operation

Governed sessions

Look at the operation a session is attached to. Remote access is launched by policy against a specific piece of work — it is not a separate tool opened alongside it.

Governed Sessions →

Two honest edges here. Session evidence is deliberately narrow today: we describe governed launch, authorization and the operation record, and we do not claim full multi-surface session replay. And a credential record is a password-safe entry a human may also use — managed means we own its rotation, and only after a deliberate designation, not by default.

The evidence

Where it turns into something you can send.

The last three surfaces are the commercial ones. Everything upstream exists so that these can be handed to somebody outside your team without a covering explanation.

A Seraph outcome receipt with its audit chain, showing the authorization, the lease, the job, the machine's confirmation and the declared undo

Outcome receipt & chain

Look at the confirmation line and the fingerprint under it. One says the target machine answered; the other is what makes editing the record afterwards visible to anyone who checks.

Outcome Receipts →
The Seraph reporting surface, showing delivery metrics and client-ready evidence exports

Reporting & exports

Look at what an export is scoped to — one client, one period — and that it goes out as PDF, JSON or CSV with the proof attached. Exports are included in the published package scope.

Reporting & Exports →
The Seraph roles and multi-tenancy surface, showing roles scoped across customers

Roles & multi-tenancy

Look at how scope is expressed. It is identity crossed with customer, not a single flat role list, and an operator can hold more than one live context at a time.

Roles & Multi-Tenancy →
The one surface with no screenshot hereAutomation & Runbooks is the authoring side rather than the operating side, so it does not belong in a console tour — but it is where the verification and the rollback on every screen above are actually written, before anything is allowed to run.

Screens are the weakest form of proof

Have us drive them instead.

A screenshot proves an interface exists. Fifteen minutes on a live system proves the record does — a real ticket resolved end to end, the record opened, the rollback executed, and your hardest audit question answered on the call.

Book a demoScore us against the spec
← PreviousThe operation recordFrom request to result and recovery review Next →Security & architectureWhat the AI can never see