Series voir-pages
page 08 / 26
department 1 of 8
stations implemented 0

Operations is not “keep an eye on things”. It is a five-station line, monitoring and escalation without self-deception.

Q: Is the operations department working yet?

Not as a VOIR AI product. All five stations on this page describe the target architecture: not one of them is implemented in the product code. The line demo runs a pre-written scenario and is not connected to a live AI service. Separately, the Marisova ecosystem exists, where a task dispatcher, a decision journal, a session observer and health probes run as our own internal tools — they are not part of the VOIR AI product and are not offered to customers.

Q: Does the monitoring fix incidents by itself?

No. In the target architecture the monitor bus detects a deviation and records it with evidence; the decision to intervene belongs to a human, or to the execution station acting on a rule that was written down beforehand. “Fix everything silently” is exactly the scenario where an incident gets masked instead of removed: the system reports green while the work stands still.

Q: Which metrics does the line show?

This page carries no invented efficiency numbers: no SLA, no success rates, no “times faster” claims. The counters under the stations count only the points of the prepared demo scenario, and they are zero in a static frame. The structural numbers are five stations, three supporting contours, eight departments in the architecture, and zero stations implemented in the product.

The operations department in VOIR AI holds the recurring processes: a task enters a playbook, is broken into a plan, is executed with an action log, passes an independent check and leaves as a report to the owner. Above the line runs the monitor bus — probes on a schedule, not “when someone notices”. Below it runs the escalation bus: anything a station could not resolve goes to a human instead of disappearing silently. What follows is the honest picture: what the department is meant to do in the target architecture, what already runs inside our own tooling, and how the department sits inside the AI CEO cycle.

VOIR AI product · zero stations implemented Marisova ecosystem · task dispatcher and decision journal

See the department line Honest status

The line · department stations

VOIR-OP/08

IN Task in input

TRG Process playbook not implemented

PLN Run plan not implemented

EXE Execution and log not implemented

CHK Independent check not implemented

RPT Owner report not implemented

MON Monitoring · scheduled probes bus

ESC Escalation · decision belongs to a human bus

CYC Loop into the next run cycle

The station fill bars are zero on purpose: not one station of the line is implemented in the VOIR AI product. The functions that already run as our own internal tooling are listed separately in the status table.

Demo · the department line

One task, five stations, three supporting contours

A line without an escalation bus looks perfect and lies: on it, every task reaches the report. The real diagram is different. At any station the work can stop — data is missing, access is missing, the decision exceeds the role's autonomy grade. Then the task drops onto the escalation bus and goes to the owner together with a description of what exactly failed. From above, the monitor bus accompanies the line: probes run on a schedule, not on the strength of someone's attention. Below is the same structure described in the “Five stations” section.

Structural numbers of the page: 5 line stations, 3 supporting contours, 8 departments in the architecture, 0 stations implemented in the product.

The line · task → stations → escalation → report → next run

Demo · prepared scenario

INThe task enters the line from AI CEO together with acceptance criteria fixed before the start. Without criteria the task is not accepted: there would be nothing to check against.
TRGPlaybook station: the process is matched against the written one — steps, an owner per step, inputs and outputs, what counts as done. If no playbook exists, it is created and fixed before work begins.
PLNPlan station: the task is broken into steps with dependencies and dates, executors are assigned, and the artifact of each step is named in advance.
EXEExecution station: steps are carried out and every action is written to the log — what was done, with what, when, and which artifact came out. The log is part of the result, not housekeeping.
CHKCheck station: the result is matched against the playbook criteria by a role that did not do the work. The verdict is VERIFIED, or rework with a list of discrepancies.
RPTReport station: the run is folded into an owner report — what was done, what was rejected, what slipped, which decision stayed with a human.
MONMonitor bus: scheduled probes come down to the stations and verify the loop is alive. A deviation is recorded with evidence; the decision to intervene belongs to a human or to a station acting on a rule written down beforehand.
ESCEscalation bus: a task a station could not resolve on its own goes to the owner with the step and the reason attached. A station cannot drop a task silently — escalation is recorded as the outcome of the step.
CYCLoop into the next run: the report changes the playbook. Check findings, missed dates and escalations return to the TRG station, and the next run follows a corrected process.

The demo runs a pre-written scenario and is not connected to a live AI service. The “demo” counters under the stations count only the points of that scenario: in a static frame and with motion disabled they are zero. This is not an SLA, not throughput, and not data about real customer processes — the project has no customers.

Target architecture

Five stations: input, work, output, artifact

A station is not “a stage of work in general” but a contract: what comes in, what is done, what comes out and which artifact remains after the step. If a station has no artifact, it cannot be checked independently — and therefore cannot be improved. All five stations on this page share one status: they are not implemented in the VOIR AI product.

TRG 01 / 05

Target architecture

Playbook

inputa recurring process, or a task that has no process yet
outputa written playbook: steps, owners, definition of done per step

The first station answers not for speed but for repeatability. A process that lives in one executor's head is not a process — it is a risk: it disappears together with the executor. The playbook is written before the work starts, not reconstructed after the fact, and it always contains the condition under which a step is handed to a human.

artifactthe process playbook: steps, an owner per step, inputs and outputs, definition of done, escalation conditions

PLN 02 / 05

Target architecture

Plan

inputthe task from AI CEO, the playbook, deadline and resource limits
outputa run plan: steps, dependencies, executors, named artifacts

A plan differs from a to-do list in that dependencies are visible: what cannot start until something else finishes, and what happens if a step fails. The artifact of each step is named in advance — before execution, not invented afterwards. Otherwise there is no way to tell completed work apart from a report about it.

artifactthe run plan with dependencies and dates, assigned executors, the list of expected artifacts per step

EXE 03 / 05

Target architecture

Execution

inputa plan step, the step playbook, the access and data the work needs
outputthe step artifact and a log entry: what was done, with what, when

Execution keeps the action log as it goes, not reconstructed after the fact. If a step fails — data is missing, access is missing, the decision exceeds the role's autonomy grade — the executor does not substitute a “similar-looking” result and does not stay silent: the step goes onto the escalation bus with the reason attached.

artifactthe step artifact plus the execution log: the sequence of actions, timing, sources used, escalation marks

CHK 04 / 05

Target architecture

Check

inputthe step artifact, the execution log, the playbook acceptance criteria
outputa verdict: VERIFIED, or rework with a list of discrepancies

The check is performed by a role that did not do the work. The executor's self-check remains, but only the independent verdict reaches the report. A separate duty of the station is to catch false-green gates: the case where a gate passes precisely because the defect is masked by the checking mechanism itself.

artifactthe check verdict with the list of verified criteria, the discrepancies, and what instrument verified each claim

RPT 05 / 05

Target architecture

Report

inputverified artifacts, check verdicts, escalations, missed dates
outputan owner report and playbook edits for the next run

The report shows the run as it was: rejected artifacts, missed dates and escalations land in it without smoothing. A report with no bad lines is a sign that the station works for impression, not for control. The station's final act is a playbook edit: the CYC loop closes back onto TRG.

artifactthe owner report: done, rejected, slipped, escalated; the list of playbook edits for the next run

Monitoring

The monitor bus: what gets probed on a schedule

Monitoring that only switches on when someone has noticed a problem is not monitoring — it is a reaction after the fact. The MON bus works differently: every probe has a schedule, a measured quantity, a threshold and a reaction written down in advance. Below is the target architecture of the observation contour; each probe is declared before it can ever be needed.

every step

Is the loop alive

A probe per station: does the process respond, is the line moving, has the run stalled on a single step. The fact of movement is measured, not the presence of a “green” status.

threshold: idle longer than set · reaction: log entry and escalation

every run

Was the playbook followed

The actual sequence of steps is matched against the written one: skipped steps, steps without an artifact, artifacts that never passed the check. A deviation is not “a variant of normal” — it is a finding.

threshold: any discrepancy · reaction: return to the TRG station

on schedule

Has the result gone stale

A drift probe: the data the report was built on may have changed. What is checked is not the quality of the past work but its fitness now — otherwise the report confidently describes a state that no longer exists.

threshold: divergence from current state · reaction: recompute and mark in the report

every escalation

Are unresolved ones piling up

The ESC bus is worked through: every escalation must receive a human decision and a closure mark. An escalation without an answer is not “pending” — it is a lost task, and the bus is obliged to show that.

threshold: escalation without a decision · reaction: notify the owner again

every report

Is a gate false-green

A check of the check: does the gate have a negative control — a deliberately defective input on which the gate must fail. A gate that always passes measures nothing and manufactures an illusion of quality.

threshold: gate without negative control · reaction: “not verified” mark in the report

The schedules and thresholds are parameters of the target architecture, not statistics: they set the rhythm of observation in which a failure is found by a probe rather than by a complaint. The project has no real data about which intervals work better, because the product is not running; we are not going to invent a “mean time to detection”. How the department receives its tasks and who sets the criteria is described in the “AI CEO cycle” section and on the AI CEO page.

Automating routine

What a written-down process consists of

Only what is written down can be automated. “Do it like last time” is not a playbook: last time you might have been lucky. That is why the TRG station requires the same set of fields from any process that claims to be repeatable. A process without these fields stays manual work, and we say so plainly instead of calling it automation.

Steps and order

What is done, in which order, and which steps cannot be swapped. The order is fixed because swapping steps changes the result: checking before execution and after it are two different processes.

An owner per step

The role responsible for the step and its autonomy grade: what the role does alone, what it coordinates, and what must go to a human. A step without an owner gets done “somehow” — or not at all.

Step input and output

What the step takes in and which artifact it leaves. The artifact is named before execution: if it is formulated afterwards, it is easy to pass off whatever came out as the result.

Definition of done

A checkable condition under which the step counts as done. It is worded so that a role which did not perform the work can verify it — otherwise the check turns into trust.

Escalation conditions

Which signs stop the step and hand it to a human: data is missing, access is missing, the action is irreversible, the spend exceeds the frame. Escalation is described up front, not invented at the moment of failure.

Revision procedure

Who changes the playbook, on what grounds, and where the edit is recorded. A process with no revision procedure goes stale silently: it keeps being followed formally while the real work has moved on.

Reporting

The report: what is in it and what is left out on purpose

The operations report does not exist to show the volume of work. Its job is to let the owner make a decision: what to stop, what to repeat, where data is missing. That is why the report's composition is declared in advance — and half of its lines are about what did not work.

What goes into the report

Completed steps and each step's artifact — with a pointer to where the artifact lives
Independent check verdicts: what was verified, with which instrument, what was confirmed
Rejected artifacts with the list of discrepancies, not a vague “did not pass”
Missed dates and the dependencies that shifted because of them
Escalations: which decisions stayed with a human, at which step
Playbook edits this run proposes for the next one
Open questions and explicit “no data” marks where there really is no data

What is deliberately left out

Invented efficiency percentages and “times faster” claims — there is nothing to measure yet
Smoothed wording: “largely done” instead of the list of discrepancies
Hidden escalations: a human decision is never presented as an automatic result
Green statuses without proof: every “verified” names the instrument that verified it
Metrics that cannot be re-checked from the execution log
Borrowed credit: if another role did the work, the report names that role

The playbook edits are not an appendix to the report but its main output: they are what closes the CYC loop and makes the next run better than the previous one. A report after which the process did not change remains a protocol of intentions. The acceptance machinery the artifacts pass through is described on the AI CEO Cycle page; the roles that perform the steps are on the AI Employees page.

Status

An honest matrix: product and ecosystem are different things

The most common mistake on pages like this one is presenting an internal working tool as if it were a product capability. We keep two columns apart. First: what is implemented in the VOIR AI product (right now — not one station of the line). Second: what already runs inside our Marisova ecosystem as our own tooling. The second column is not for sale and is not provided to customers.

Status of the operations department functions as of 2 November 2026. Verified against the code, configuration and live URLs — not against plans.
Function	In the VOIR AI product	In the Marisova ecosystem (internal)
Process playbooks (TRG)	not implemented Target architecture: a written process with criteria	works Playbooks exist as task files and pipeline descriptions in our working directory: a task carries its brief, its boundaries and its closing criterion. Not offered to customers as a service
Run plan (PLN)	not implemented Target architecture: a plan with dependencies and dates	works A task queue with states: in progress, blocked, done, rejected. Order and blockers are visible, but this is our internal dispatcher, not a product
Execution with a log (EXE)	not implemented Target architecture: step artifact plus action log	works Every task leaves a completion report and entries in the decision journal; reports are checked separately from the executor. Internal tooling
Independent check (CHK)	not implemented Target architecture: a verdict by a role that did not do the work	works The practice of independent acceptance exists: claims are verified against the disk, git and live URLs, not against the executor's report. Not a product
Owner report (RPT)	not implemented Target architecture: a run report with playbook edits	works Task reports are written to a single results directory and read by the owner; some carry explicit blocker marks. Internal contour
Scheduled monitoring (MON)	not implemented Target architecture: probes, thresholds, a written reaction	works A scheduler launches the observer and health probes on a schedule; there is a live log of triggers. Our own tooling
Escalation to a human (ESC)	not implemented By architecture — a mandatory station output	works The rule holds in practice: irreversible actions and actions on production require confirmation, and task blockers are recorded explicitly rather than hushed up
Customer operations dashboard	not implemented Target architecture: process state in one place	prototype A local map of our internal process state exists as a prototype for ourselves. It is not a customer interface and not a public service

The works label refers to our internal tools that we use in our own projects. It is not a VOIR AI product feature and not a promise to a customer. There are deliberately no throughput, SLA or “routine speed-up” numbers here: the project has no customers and the product is not running. The actual project status is published on the About page; the platform design is on the AI Operating System page.

Link to AI CEO

The operations department does not assign itself work

Operations in VOIR AI is the executive part of the AI CEO cycle. AI CEO takes the task and decides what goes to operations: setting up a recurring process, tracking deadlines, diagnosing a broken execution chain. It also folds the result into the owner report. The department artifacts pass independent acceptance by a role that did not perform the work. The table below shows what exactly the department does at each of the five steps of the cycle.

01 Task setting The department receives a brief and acceptance criteria fixed before the start: which process we take, what counts as the result, which limits apply to access and irreversible actions. Operations does not set its own tasks — otherwise the department starts “optimising” things nobody asked to change.
02 Analysis and assignment AI CEO decides which part of the work goes to operations and spreads it across the department roles: the playbook to one role, the plan and dependencies to another, execution and the log to a third, the check to a fourth. The autonomy grade is fixed: what a role does alone and what must go to the owner for confirmation.
03 Execution The roles move the task along the stations: playbook, plan, execution, artifacts. Every role keeps a trail of actions and passes the artifact on together with the sources of its facts, or with an explicit “no data” mark. Irreversible actions and actions on live systems require human confirmation at this step.
04 Independent check A QA role that did not run this process matches the artifacts against the criteria of step 1: does the artifact exist on disk, is the check reproducible, is there a false-green gate, are blockers reflected honestly. The verdict is VERIFIED or REJECT with a list of discrepancies.
05 Acceptance and report AI CEO folds the verified artifacts into one owner report: what was done, what was rejected, what slipped, which decisions stayed with a human, which playbook edits are proposed for the next run. Rejected artifacts and misses land in the report as they are, without smoothing.

Department roles in the target architecture

PRC

Process engineer

Runs the TRG station: writes the process down, declares step owners and acceptance criteria, describes the escalation conditions. Does not start automating what has not been written.

SCH

Schedule dispatcher

Runs the PLN and EXE stations: breaks the task into steps with dependencies, assigns executors, keeps the execution log and makes sure a failed step is visible immediately, not at the end of the run.

OBS

Loop observer

Runs the MON bus: scheduled probes, thresholds, evidence of deviations. Does not fix things itself — it records and hands over to the execution station or the owner, together with what instrument measured it.

Artifacts the department leaves behind

Process playbooksteps, owners, inputs and outputs, definition of done, escalation conditions
Run plandependencies, dates, assigned executors, expected artifacts
Execution logthe sequence of actions, timing, sources, escalation marks
Check verdictthe list of verified criteria and the instrument behind each
Monitoring deviation logprobes, thresholds, the fact of deviation, evidence, reaction
Escalation registerwhat went to a human, at which step, which decision was made, is it closed
Run reportdone, rejected, slipped, escalated, playbook edits

Touchpoints with neighbouring departments

AI CEO → operations The task arrives with acceptance criteria and autonomy grades. Without them the check station cannot deliver a verdict, and the process turns into work “by eye”.
Development → operations AI agents and integrations give the department its execution tools; operations in return demands an action log and explicit errors from them, not a silent fallback.
Operations → support A break in the execution chain found by the monitor bus goes to support as an incident with a description and evidence, not as “something is not working”.
Operations → marketing and sales Dates and dependencies from the run plan are an input for marketing and sales: a date can only be promised to a customer once it is visible in the plan.
Operations → owner and QA All station artifacts go to independent acceptance, and irreversible actions go to the owner for escalation. No role declares a run closed on its own.

How a single executor is built — on the AI Agents page; how a staff assembles several departments for one task — on the AI Teams page; the roles across all departments — on the AI Employees page.

Limits

What the operations department never does

Operations is a domain where automation is doubly tempting: here it is easy to “fix” something silently and report green. That is why the limits are built into the station contract, not into settings: no role of the department can route around them.

Never fixes silently

Every intervention in the process is written to the log: what changed, by whom, why, under which rule. A silent recovery is a failure you simply cannot see; next time it repeats at a higher cost.

Never swaps in a look-alike result

If the step artifact was not produced, the step is not declared done. Substituting something roughly similar for the required artifact counts as a defect and is rejected at the check.

Never trusts a green gate

A check without a negative control is not a check. The gate must fail on a deliberately defective input — otherwise it measures not quality but its own leniency.

Never invents metrics or customers

No SLA, no run success rates, no “routine times faster”, no testimonials or logos. If there is no data, the mark reads “no data”. This page carries no efficiency numbers at all, because the product is not running.

Never performs the irreversible without a human

Deletion, overwriting someone else's work, edits to live systems and production — only after the owner confirms, and only with a backup of whatever is touched. No one raises the role's autonomy grade here, including the role itself.

Never accepts its own work

The role's self-check remains, but only the verdict of independent acceptance reaches the report. A playbook or a log that never reached the check does not exist for the report.

Questions

What people ask about AI Operations

Is the operations department working yet?

Not as a VOIR AI product. All five stations of the line on this page describe the target architecture: not one of them is implemented in the product code. The line demo runs a pre-written scenario and is not connected to a live AI service. Separately, the Marisova ecosystem exists, where a task dispatcher, a decision journal, a session observer and health probes run as our own tools. They are not part of the VOIR AI product and are not offered to customers.

What does the “Target architecture” status mean?

It is an honest mark that a function is designed in the project but not implemented in the product. We keep two statuses apart: “target architecture” — how the department is meant to work in the VOIR AI design; and “works in the ecosystem” — the tool already exists and we use it internally. The second never implies the first: a customer does not get an internal tool.

Does the monitoring fix incidents by itself?

No, and that is an architectural decision, not a temporary limitation. The monitor bus detects a deviation and records it with evidence; the decision to intervene belongs to a human, or to the execution station acting on a rule written down beforehand. “Fix everything silently” is exactly the scenario where an incident gets masked instead of removed: the system reports green while the work stands still.

What happens when a task cannot be done automatically?

It goes onto the escalation bus ESC and from there to the owner — together with a description of what exactly failed, at which step and why. The task is never dropped silently and never marked as done. Escalation is a normal station output, not an emergency path: the playbook must state the conditions under which a step is handed to a human, and those conditions are declared before the work starts.

Which metrics does the line show?

No efficiency metrics appear on this page on purpose: no SLA, no run success rates, no time-to-detection, no “routine times faster”. The “demo” counters under the stations count only the points of the prepared demo scenario, and in a static frame and with motion disabled they are zero. The structural numbers are five stations, three supporting contours, eight departments in the architecture, zero stations implemented.

How is the operations department connected to AI CEO?

The department does not assign itself work. AI CEO takes the task and the acceptance criteria, spreads the work across the department roles — process engineer, schedule dispatcher and loop observer — folds the result into the owner report and decides what changes in the next cycle. Station artifacts pass independent acceptance by a QA role that did not run the process. Details are on the AI CEO and AI CEO Cycle pages.

Can the operations department be used apart from the platform?

By architecture — it makes no sense. The line runs on shared platform data: tasks come from AI CEO with criteria, execution tools come from development, incidents go to support, marketing and sales read dates from the plan, acceptance runs through the common machinery. A standalone “AI operations manager” without this data turns into a report generator with nothing to check against.

Where to go from this page

Operations is one of eight departments: AI CEO sets the task, development supplies the tools, and marketing and sales read the dates from the plan.

Process

See pricing Ask about the platform