VXCTRLEnterprise control tower
Platform

Engines that each own one domain, and one path every write must take.

VXCTRL is a set of Rust services. Six of them form a spine that every governed write has to pass through; the rest own the domains the business actually runs on. The separation is the design: deciding and doing are never the same engine's job.

The short answerThe VXCTRL platform is a set of Rust engines, each owning exactly one domain. Six are the required spine: Core, Identity, Hierarchy, Policy, Monitoring and Audit. Every governed write passes through all six, in order, and the engine that owns the domain does the work only once Policy has allowed it.
01The governed flow

What happens between a request and a result?

Seven stages, always in the same order. Core, Identity, Hierarchy, Policy, the engine that owns the domain, Monitoring, then Audit. Nothing reaches the engine that can change state until the first four stages have agreed that it may.

How a governed action flows through VXCTRL Seven stages in fixed order: Core, Identity, Hierarchy, Policy, the owning engine, Monitoring, Audit. A refusal at Identity, Hierarchy or Policy stops the write but is still logged and sealed. 01 Core Routing and registry. Every governed write enters here. 02 Identity Who is asking. Verified session, argon2id passwords, signed and revocable tokens. 03 Hierarchy Where they sit in the six-level tree, and whether the target is inside their reach. 04 Policy Deny by default. Nothing is allowed unless a priority- ordered rule allows it. REFUSED, STILL LOGGED AND SEALED 05 Owning engine The engine that owns the domain does the work, only now that it is permitted. 06 Monitoring Every action and every refusal, logged to a hash-chained operational log. 07 Audit The outcome is sealed onto an append-only audit ledger. Of-record. The outcome can be replayed and checked.
How a governed action flows through VXCTRL Seven stages in fixed order: Core, Identity, Hierarchy, Policy, the owning engine, Monitoring, Audit. A refusal at Identity, Hierarchy or Policy stops the write but is still logged and sealed. 01 Core Routing and registry. Every governed write enters through Core. 02 Identity Who is asking: verified session, argon2id passwords, signed and revocable tokens. 03 Hierarchy Where they sit in the six-level tree, and whether the target is inside their reach. 04 Policy Deny by default. Nothing is allowed unless a priority-ordered rule allows it. 05 Owning engine The engine that owns the domain does the work, only now that it is permitted. 06 Monitoring Every action and every refusal, logged to a hash-chained operational log. 07 Audit Sealed onto an append-only audit ledger. A REFUSAL STOPS AT ITS STAGE, STILL LOGGED AND SEALED
Figure 1The governed flow. Every write passes through every stage, in order. A refusal at Identity, Hierarchy or Policy stops the write, and is still logged by Monitoring and sealed onto the audit ledger, so a denial leaves as much evidence as an approval.

A refusal is not a dead end in the record. Monitoring logs every action and every refusal to a hash-chained operational log, and Audit seals the outcome onto an append-only ledger, so a denial is evidence in exactly the way an approval is. If someone asks six months later why a write did not happen, there is an answer.

  1. Core: routing and registry

    Core knows which engine owns which domain. A governed write enters the system here and is routed from here.

  2. Identity: who is asking

    A verified session, argon2id password hashing, signed session tokens, and sessions that can be revoked.

  3. Hierarchy: where they sit, and what they can reach

    The caller's position in the six-level tree, and whether the target of the action is inside their reach at all.

  4. Policy: deny by default

    Nothing is allowed unless a rule allows it. Rules are priority-ordered and audited, and grants are scoped by level and by address class.

  5. The owning engine: the work

    The engine whose domain it is performs the write. It does not make the decision; by the time it is reached, the decision has been made.

  6. Monitoring: the operational log

    Every action and every refusal is written to a hash-chained operational log.

  7. Audit: the seal

    The outcome is sealed onto an append-only audit ledger. From that point it is of-record.

02The spine

Which engines are required?

Six. They are required because the governed flow runs through all of them, so there is no configuration in which a write can avoid them. Remove any one and there is no longer a control plane, only a set of services that trust each other.

Core
Routing and registry. Knows which engine owns which domain, and is where a governed write enters.
Identity
Who is asking: verified sessions, argon2id password hashing, signed session tokens, revocable sessions.
Hierarchy
Where the caller sits in the six-level tree, and whether the target is inside their reach.
Policy
Deny-by-default rules. Nothing is allowed unless a rule allows it; rules are priority-ordered and audited.
Monitoring
Every action and every refusal, logged to a hash-chained operational log.
Audit
The outcome, sealed onto an append-only audit ledger.
03The other engines

What else runs alongside the spine?

Thirteen more engines, which with the spine makes 19 in the running fleet today. Five of them carry a governance role; the other eight own the domains the business runs on. Each owns exactly one domain, and each is reached through the same governed flow as everything else: being an engine grants no special path.

The engines that carry a governance role

AI Governance
Which AI models each level may use, with interactions logged.
Terminal
The approval gate: where a promotion or a sensitive action is held for approval.
DIN
The evidence link: the connection to field-recorded evidence recorded in DIN CTRL, the separately sold product that keeps it, when a customer connects it.
Consciousness
The AI-tier mirror of the org.
Echoron
Security posture.

The domain engines

Automation
Trigger-to-action rules that fire across engines. Every execution is logged for audit.
Domain
The domains each brand owns, and their DNS, certificates and web presence.
Builder
Templates for creating standardised entities (teams, locations, roles) consistently at scale.
Knowledge
Versioned documents (SOPs, policies, training, reference) with tagging, search, a publish step and level-scoped visibility.
Files
File records with quotas, versioning, checksums and permission-aware sharing down the tree.
Analytics
Metrics with thresholds: record data points, compute aggregates, raise an alert on a breach.
Integration
Registered webhooks and event routing to outside systems. Outbound destinations are allow-listed: no private, loopback or metadata addresses.
Infrastructure
The server estate: the hosts, their health and their capacity.

None of these is a privileged path. Each one is reached through the same governed flow as everything else, and none of them can grant itself reach it was not given.

04Why it is shaped this way

Why separate deciding from doing?

Because an engine that can both decide and act can talk itself into anything. In VXCTRL the engine that owns a domain never evaluates its own authority: Identity, Hierarchy and Policy have already done that, in that order, before the engine is reached at all.

The same reasoning explains why Monitoring and Audit come after the work rather than being the engine's responsibility. An engine that wrote its own audit record could choose what to write. Here the record is produced by stages the engine does not control, which is what makes it worth keeping.

Want the engine list against your own domains?

Tell us which domains you need governed and we will map them onto the engines that exist today. Email reaches a real mailbox.

Email support@vxctrl.comSee the platform
FAQQuestions

Questions people ask before they commit

What is the VXCTRL platform made of?

Rust services called engines, each owning exactly one domain. Six of them are the required spine: Core, Identity, Hierarchy, Policy, Monitoring and Audit. Thirteen more run alongside the spine to cover AI governance, automation, domains, building, knowledge, files, analytics, integration, infrastructure, the DIN evidence link, the AI-tier mirror of the org, security posture, and the approval gate.

How many engines are running?

19 in the running fleet today: the six-engine spine, five engines that carry a governance role, and eight domain engines. The number matters less than the shape: the spine is required, so no engine and no configuration can route around it.

What is the required spine?

Core provides routing and registry. Identity establishes who is asking. Hierarchy establishes where they sit in the six-level tree and whether the target is inside their reach. Policy decides, deny-by-default. Monitoring logs every action and every refusal. Audit seals the outcome. Those six are required because every governed write passes through all of them.

Can a stage of the governed flow be skipped?

No. Every write goes through every stage, in order: Core, Identity, Hierarchy, Policy, the owning engine, Monitoring, then Audit. The ordering is the point: the engine that does the work is reached only after the decision has already been made elsewhere.

Why does each engine own only one domain?

So that the decision to allow an action and the work of performing it never live in the same place. The owning engine performs the write; Identity, Hierarchy and Policy decide whether it may. An engine cannot grant itself reach it was not given.

What does the Terminal engine do?

Terminal is the approval gate. It is the engine through which approved facts from the field are promoted into the system of record, and it is where a sensitive action is held for a second approver when that is required.

What is the Consciousness engine?

Consciousness is the AI-tier mirror of the org. It is the engine that represents the organisation's AI tier in the same shape as the rest of the tree, so AI actors can be governed by the same model as people and machines.