• Series voir-pages
  • page 10 / 26
  • department 5 of 8
  • functions implemented 0

AI HR is not “pump out job posts faster”. It is a role profile, criteria-based screening and a review grounded in artifacts, not impressions.

The people function in VOIR AI runs the full hiring loop: from the role profile to the periodic review. A requisition is assembled from the requesting department's requirements and its readiness criteria — one source, not two email threads. Applicants are screened against criteria announced in advance, and every verdict carries a reason and a reference to the criterion. Onboarding is a checklist with checkpoints, and the review is a cut across artifacts and acceptances, not across moods. The decisions to hire, to let go and to raise a role's autonomy grade always stay with a human. Below is an interactive demonstration on fictional data: a hiring rail of four stations, plus the tables the diagrams are built from. Next to it is the honest picture: what the department should do according to the target architecture, what already runs internally as our own tooling, and how the department is wired into the AI CEO Cycle.

VOIR AI product · zero functions implemented Marisova ecosystem · task journal and agent acceptances Demonstration · candidates are fictional

Open the hiring rail Honest statuses

Demonstration · the hiring rail

Four stations: requisition, screening, onboarding, review

Hiring in VOIR AI works like a rail along which a role travels from requisition to periodic review. The first station is the requisition brief: the requesting department's requirements and readiness criteria are fixed before the first applicant shows up. The second is screening: a punch-card of criteria where every applicant is checked against positions announced in advance, and every verdict carries a reason. The third is onboarding: a role entry checklist with checkpoints. The fourth is the review: a cut across artifacts and acceptances. Every station is duplicated by a table or a list — the diagram is built from the data, not the other way around. The candidates, companies and numbers are fictional, made up by us for illustration.

Structural numbers of this page: 4 department functions, 4 rail stations, 8 departments in the architecture, 0 functions implemented in the product.

Hiring rail · requisition → screening → onboarding → review

Demonstration · fictional data

Station 1 · Requisition: the role profile comes before applicants

A requisition is not “copy to attract” — it is a contract: what the role does, by which criteria its work counts as done, and which boundaries it has. The requesting department formulates the tasks, the people function turns them into a role profile, and finance confirms the budget for the position. All three inputs are merged into one brief before publication — otherwise the screening criteria have to be invented while applicants are already coming in, and they start to drift. Below is an example brief for the fictional role “Support Analyst” in a fictional company.

  • Role · code Support Analyst (SUP-ANL) — support, first line
  • Requester Support department; the task is triaging incoming requests and drafting standard replies
  • Readiness criteria Every reply references the knowledge base; every escalation carries the full history; the share of unrecognized requests is tracked honestly
  • Role boundaries Does not edit the knowledge base without acceptance; does not close a request without a reply; does not raise its own autonomy grade
  • Position budget Confirmed by finance before publication (demo value, arbitrary units)
  • Onboarding plan Attached to the brief: 6 steps, 3 checkpoints, mentor assigned

Demonstration: the role, company, criteria and budget are fictional. This is what the brief structure looks like in the target architecture — in the VOIR AI product the requisition is not implemented.

Station 2 · Screening: the criteria punch-card

Every applicant is “punched” against the same set of criteria — like a punch-card: a position is either closed or it is not, and there is no third state. The criteria are announced before screening and are not moved to fit a candidate we happen to like. There are three verdicts: “next stage” — all mandatory positions are closed; “reserve” — some are not, and the gap is named; “decline” — a mandatory position is not closed, and the card shows it without interpretation. Below are fictional applicants for the fictional role SUP-ANL; exact data lives in the table under the diagram.

Screening punch-card: five fictional applicants against six criteria. A green cell means the criterion is met, amber means partially met, red means not met. Exact verdicts are in the table below. C1 EXPERIENCE C2 KB C3 TONE C4 ESCAL C5 SLA C6 BOUNDS Applicant A Applicant B Applicant C Applicant D Applicant E
  • criterion met
  • partially met — reason in the table
  • not met
The screening table — the data source for the punch-card. All applicants and companies are fictional. C1 — support-line experience, C2 — knowledge-base work, C3 — reply tone, C4 — escalation rules, C5 — reply-time discipline, C6 — understanding of role boundaries.
Applicant Strength Gap Verdict and reason
Applicant A Experience, knowledge base, escalations — all closed C5: reply-time discipline confirmed at only one previous place next stage — all mandatory criteria met; the C5 gap is minor and is verified during probation
Applicant B Tone, escalations, timing, boundaries C2: has not worked with a knowledge base reserve — mandatory C2 not met; it can be trained, but not before the start date
Applicant C Knowledge base, escalations, timing C1 and C3 partially; C6 — shaky grasp of role boundaries reserve — two mandatory positions only partially met; the reason is named and the criterion was not bent for the candidate
Applicant D Reply tone C1, C2, C5 not met; C4 partially decline — three mandatory positions not met; the verdict reads off the punch-card without interpretation
Applicant E All six criteria met none next stage — full profile; the next step is scheduled by a human, not by the system

Demonstration: the applicants are fictional. The target-architecture rule: criteria are announced before screening and are not bent for a candidate; “reserve” is not a polite decline but a named gap with a path to close it.

Station 3 · Onboarding: the role entry plan

Onboarding an AI employee is built the same way as onboarding a human: a role is not “switched on” in full on day one. Access is granted as needed, context is dosed, the first tasks run under a mentor's acceptance, and checkpoints verify not “did we like it” but “do the artifacts match the brief's criteria”. Below is a six-step entry plan with three checkpoints for the fictional role SUP-ANL.

  1. Step 1 · Access contour The role receives only the access its first tasks need. Extension goes through a request confirmed by a human — never self-granted. Checkpoint 1: the access list is reconciled against the brief.
  2. Step 2 · Role context The knowledge base, tone rules, escalation rules and role boundaries are loaded as a reference layer. The role must cite this layer in its replies instead of answering “from its head”.
  3. Step 3 · First tasks under supervision The first requests are handled in draft mode: the reply goes to the mentor, not to the customer. The mentor edits or accepts. Checkpoint 2: the share of drafts accepted without edits is not below the threshold from the brief.
  4. Step 4 · Solo mode with acceptance The role answers on its own, but every tenth reply and every escalation passes spot acceptance. Deviations are recorded in the journal, not swept under the rug.
  5. Step 5 · Incident review Each incident (a wrong reply, a missed escalation) is reviewed separately: cause, the rule that failed, the change to the reference layer. We do not look for someone to blame — we look for the rule.
  6. Step 6 · End of probation A cut across artifacts: the reply journal, acceptance share, incidents, positions with no data. The decision “keep in role / extend probation / return to screening” is made by a human. Checkpoint 3: the outcome is signed off by the role's requester.

Demonstration: the plan is fictional, made to illustrate the structure. In the VOIR AI product the onboarding loop is not implemented; in the Marisova ecosystem a similar principle already runs in internal tooling — see the status table.

Station 4 · Review: a cut across artifacts, not impressions

The periodic review of a role is assembled from what the role left behind: artifacts, acceptances, incidents, positions with no data. A review cannot say “did well” — every statement leans on a journal entry. The review does not change the autonomy grade automatically: it only prepares the cut by which a human makes the decision. Below is the review card of a fictional role for a fictional period.

  • Artifacts of the period The reply and escalation journal: every request is an entry with a source and an outcome. Positions with no data are marked “no data”, not closed with a guess.
  • Acceptances The share of artifacts accepted by the independent role at the first pass; the share rejected with a reason. Rejections are not a penalty — they are input for a rule review.
  • Incidents The list of incidents with the root of each: which rule of the reference layer failed. A repeating root is a signal to change the rule, not the role.
  • Human decision Keep in role / widen tasks / change autonomy grade / end the role's work. The decision and its reason are recorded in the role's personnel file.

Demonstration: the review card is fictional. In the VOIR AI product the performance review is not implemented; the page deliberately shows no “efficiency percentages” or “productivity gains” — they do not exist.

Department roles · target architecture

The role contract: input, work, output, artifact

The people function is three roles, each with its own contract. The contract describes what the role takes as input, what it does, what it must hand over, and which artifact remains after it. A role without a contract is a “smart assistant” that helps sometimes and invents things other times; a role with a contract can be checked. All three roles below describe the target architecture: not one of them is implemented in the VOIR AI product.

Target architecture REC

Recruiter

  • InputThe requester's requisition: role tasks, requirements, budget, deadline
  • WorkAssembles the role profile and the job text from a single source; announces screening criteria before publication
  • OutputA published requisition and the set of mandatory and desirable criteria
  • ArtifactRequisition brief: requester, readiness criteria, role boundaries, budget confirmation
Target architecture SCR

Screening analyst

  • InputApplicants and the criteria announced in the requisition brief
  • WorkPunches every applicant through the criteria card; each verdict carries a reason and a reference to the criterion
  • OutputA shortlist, a reserve with named gaps, declines with reasons
  • ArtifactScreening table: applicant, closed positions, gaps, verdict, rule author
Target architecture ONB

Onboarding mentor

  • InputA role that passed screening; the brief with readiness criteria and the onboarding plan
  • WorkWalks the role through the steps: access, context, drafts under acceptance, solo mode with spot acceptance
  • OutputThe probation outcome: a cut across artifacts and checkpoints
  • ArtifactOnboarding journal: steps, checkpoints, mentor edits, incidents

Performance review

What the people loop measures — and what it never measures

The review frame is built around four groups of signals. Each group leans on records that remain from the work itself: if a signal is not in the journal, it is not in the review either. There will be no percentage promises here (“we will cut hiring time by 40%”): there is no product, there is nothing to measure, and we are not going to invent adoption metrics.

Quality of artifacts

The share of a role's artifacts accepted by independent acceptance at the first pass, and the share rejected with a reason. A rejection is not the role's fault — it is input for reviewing the rule that failed.

source: acceptance journal

Boundary discipline

Cases of stepping outside role boundaries: a reply without a knowledge-base reference, self-granted access, a request closed without an answer. Each case is reviewed separately and lands in the role's file.

source: incident journal

Data honesty

The share of positions marked “no data” versus positions closed with a plausible guess. A role that invents instead of marking “no data” loses trust faster than a role that simply makes mistakes.

source: role artifacts

Cycle speed

Time from requisition to the role's solo mode, and from an incident to a rule change. Measured to find bottlenecks, not to set norms: racing the deadline breaks acceptance.

source: cycle timestamps

Statuses

Two status columns: the blueprint and our own workshop

HR is a domain where a blueprint is especially easy to pass off as a working product: “AI hires employees by itself” sounds plausible on its own. That is why the table is split into two columns. The left one is what is implemented in the VOIR AI product (right now, not a single function of the loop). The right one is what already runs internally in the Marisova ecosystem as our own tooling. The right column must not be read as a promise to a customer: our internal work is not sold and is not transferred.

Status of the people function as of 3 November 2026. Verified against code, configuration and live URLs — not against plans.
Function In the VOIR AI product In the Marisova ecosystem (internal)
Role profile and requisition (REQ) not implemented
Target architecture: a brief assembled from the requester's requirements, readiness criteria and budget confirmation		 partially works
Internal tasks for agents are written with acceptance criteria in the task card — our own workflow, not a product. Not offered to customers
Applicant screening (SCR) not implemented
Target architecture: a criteria punch-card, a verdict with a reason and a reference to the criterion		 partially works
Independent acceptance of agent work against criteria exists as the ecosystem's internal QA loop. Not offered as a service
Onboarding (ONB) not implemented
Target architecture: a role entry plan with access, a mentor and checkpoints		 partially works
New agents in the ecosystem are introduced through the task journal and acceptances — an internal process. Not offered to customers
Performance review (REV) not implemented
Target architecture: a cut across artifacts, acceptances and incidents; the decision stays with a human		 partially works
Run journals and acceptance reports are kept for every agent task — internal reporting. Not offered as a service
The hiring rail (demonstration on this page) demonstration
Four stations with fictional candidates and numbers; not connected to a live AI service		 —

Link to AI CEO

The people function does not assign its own tasks

In VOIR AI, HR is the executive part of the AI CEO Cycle. The task is received by the AI CEO: hire a role into a department, screen a wave of applicants, prepare a performance cut, decide a role's fate at the end of probation. It also distributes the work across the department's roles and merges the result into a report for the owner. The department's artifacts pass independent acceptance by a role that did not do the work. The table below shows exactly what the people function does at each of the cycle's five steps.

  1. 01 Task setting The department receives a brief and readiness criteria fixed before the start: which role we hire, into which department, with which boundaries and budget, and what counts as successful onboarding. HR does not assign its own tasks — otherwise the department starts “improving the team” nobody asked it to review.
  2. 02 Analysis and assignment The AI CEO decides which part of the work goes to HR and distributes it across the department's roles: role profile and requisition to the recruiter, applicant screening to the screening analyst, the entry plan to the onboarding mentor. The autonomy grade is fixed: what the role decides alone, and what must go to the owner for confirmation — every hire, decline and grade change.
  3. 03 Execution The roles run the task by function: requisition brief, screening punch-card, onboarding journal, review cut. Each role leaves a trail of actions and hands the artifact on with its sources or an explicit “no data” mark. Where data is missing, the step is escalated instead of being padded with a plausible guess about a candidate.
  4. 04 Independent check A QA role that did not run this pass reconciles the artifacts against step-1 criteria: does every verdict carry a reason and a criterion reference, were the criteria changed after publication, do the onboarding checkpoints have records, are “no data” positions reflected honestly. A false-green gate is checked separately: an acceptance that always accepts checks nothing.
  5. 05 Acceptance and report The AI CEO merges the verified artifacts into one report for the owner: who passed screening and why, who is in reserve with which gap, where onboarding is on plan, which incidents are open, which decisions stayed with a human. Rejected artifacts and disputed verdicts land in the report as they are, without smoothing.

Artifacts the department leaves behind

  • Requisition briefrequester, role tasks, readiness criteria, boundaries, budget confirmation
  • Criteria punch-cardthe announced set of positions: mandatory and desirable, author of each rule
  • Screening tableapplicant, closed positions, gaps, verdict with reason
  • Onboarding journalsteps, access, checkpoints, mentor edits
  • Incident journalcase, root, the rule that failed, the change
  • Review cutartifacts, acceptances, incidents, positions with no data for the period
  • Role personnel filethe full history: hiring, onboarding, reviews, human decisions with reasons

Touchpoints with neighboring departments

  • AI CEO → HR The task arrives with readiness criteria and announced role boundaries. Without a brief, screening has no footing: the criteria would have to be invented around applicants, and they would start to drift.
  • Requesting departments → HR Any of the eight departments — from sales to finance — formulates the role's tasks in its own words; HR turns them into a profile and criteria instead of rewriting the job post “prettier”.
  • HR → development Connecting external applicant sources and workforce systems is a task for the development department. HR formulates the interface requirement: source, applicant date, idempotency of repeated uploads.
  • HR → teams The review cut goes to AI teams as input for re-assembling a squad: a role with a repeating incident root is a signal to change the rule or the lineup, not to “tune” individual performers.
  • HR → operations The onboarding plan with checkpoints goes to operations as part of the overall plan: a role that has not reached solo mode yet cannot hold a deadline on par with experienced ones.
  • HR → owner and QA All artifacts go to independent acceptance, and every hire, decline and autonomy-grade change goes to escalation to the owner. A role does not declare a hire final on its own.

How a single performer works — on the AI agents page; who exactly staffs the departments — on the AI employees page; how a squad assembles several departments under one task — on the AI teams page.

Boundaries

What the people function never does

HR is a domain where the cost of a mistake is measured in the fate of roles and people, and the temptation to “automate everything” is at its maximum. That is why the limits are built into the function contracts, not into settings: no role of the department can bypass them, including the role responsible for HR itself.

Never hires or fires on its own

The decisions to hire, decline, keep in role and end a role's work are made by a human. The department prepares the cut, the verdicts and the reasons; by architecture — not by temporary restriction — it has no signature over the decision.

Never bends criteria for a candidate

Criteria are announced before the requisition is published. If an applicant we like fails a mandatory position, they go to reserve with a named gap — the criterion is not “clarified” after the fact. Drifting criteria turn screening into a lottery.

Never reviews by impression

Every statement of a review leans on a record: an artifact, an acceptance, an incident, a timestamp. “Did well” without a journal reference does not reach the report — otherwise the review starts reflecting the reviewer's mood instead of the role's work.

Never raises its own autonomy grade

Wider access and more independence — only through a human's confirmation. A role that decides on its own that it is ready to work without acceptance is an incident, not growth.

Never invents metrics that do not exist

No “hiring accelerated by X percent”, no “productivity gains”, no testimonials or customer logos. The candidates and numbers in this page's demonstration are fictional and labeled as a demonstration: they show how the stations work, not adoption results.

Never signs acceptance of its own work

A performer's self-check remains useful, but only the verdict of a role that did not do the work carries force. A review cut that never reached independent acceptance does not make it into the outcome — for the owner, it simply does not exist.

Questions

What people ask about AI HR

Are the candidates in the demonstration real applicants?

No. Every applicant, criterion, company and verdict in the demonstration is fictional, made up by us to show how the stations work: what a requisition brief looks like, how an applicant is punched through the criteria card, how the onboarding plan is built and what the review cut is assembled from. The project has no customers, so there are no real hiring data — neither ours nor anyone else's we could show.

Does the people function already work in the product?

As a VOIR AI product — no. All four functions on this page describe the target architecture: not one of them is implemented in the product code. Separately, there is the Marisova ecosystem, where task setting for agents with acceptance criteria, independent acceptance of work and run journals exist as our internal tools. They are not part of the VOIR AI product and are not offered to customers.

Does the system make hire/decline decisions on its own?

No, and this is an architectural constraint, not an oversight. The people loop prepares: the role profile, applicant screening with reasons, the onboarding plan, the review cut. The decision to hire, decline, extend probation or change an autonomy grade is made by a human. A role cannot raise its own autonomy grade — including the role responsible for HR.

What is the criteria punch-card?

It is a set of positions announced in advance, against which every applicant is punched: a position is either closed, partially closed, or not closed — with the reason in the table. The punch-card metaphor is exact: the holes are punched before a candidate appears, and they are not moved for a particular candidate. The demonstration has six criteria and five fictional applicants — exact verdicts live in the table under the diagram.

How is onboarding an AI employee different from onboarding a human?

Structurally — not at all, and that is deliberate: access as needed, dosed context, first tasks under a mentor's acceptance, checkpoints on artifacts rather than impressions. The difference is speed and the cost of error: an AI role passes the plan in hours, but a mistake missed at step 3 is replicated across every subsequent reply. That is why supervised drafts are a mandatory step, not a formality.

Which performance metrics does the page show?

No adoption metrics at all. There is no “hiring accelerated by X percent”, no “productivity gains”, no SLAs, no testimonials or customer logos. The demonstration numbers are fictional; the counters in the text are structural facts: four department functions, four rail stations, eight departments in the architecture, zero functions implemented in the product. Anything else would be made up, and we are not going to invent metrics for a product that has not launched.

How is the people function connected to the AI CEO?

The department does not assign its own tasks. The task and readiness criteria are received by the AI CEO; it distributes the work between the department's roles — recruiter, screening analyst and onboarding mentor — merges the result into a report for the owner and decides what to change in the next cycle. The department's artifacts pass independent acceptance by a QA role that did not run this pass. Details — on the AI CEO and AI CEO Cycle pages.

Can we connect our ATS and resume database?

Not now: integrations with ATS platforms, job boards and HR systems do not exist in the VOIR AI product, and we are not writing that they will “appear soon”. Integration is a function of the development department, described as target architecture. What really exists today is listed in the status table on this page: it has two columns — “in the VOIR AI product” and “in the Marisova ecosystem” — and the second column is not a promise to a customer.

What to read after the people loop

A hired role does not exist apart from the system: it enters the AI CEO Cycle, joins a team and works as an agent with a contract. The three pages below show these connections from different sides.

Process

AI CEO Cycle

The five steps inside which the department receives a brief with role boundaries, runs hiring and onboarding, passes independent acceptance and hands the report to the owner.

Open → Who we hire

AI employees

Roles across all eight departments: how an AI employee differs from an agent and a team, and how its personnel file is designed in the target architecture.

Open → Where the role lands

AI teams

A squad under a task: how several roles from different departments are assembled into a team and how a review cut changes its lineup.

Open →

See pricing Ask about the platform