The operating system connecting IT, AI, spending and security to the reality of your business.
Start with what you need to achieve. Understand what it depends on. Bring the right people and tools together. Then establish what actually worked—and when it needs checking again. A.C.T.U.A.L. connects that whole journey across security, technology, AI, suppliers and physical operations.
Available today: consulting, implementation and fractional leadership by agreed scope.
In development: the A.C.T.U.A.L. software workspace in QUONlab. Public software access is not open. What this means for your engagement →
An order depends on people, identity, software, payments and suppliers. A factory depends on technology, premises, specialist support and recovery. A household depends on access to accounts, devices and the people who can help. Protecting the outcome means understanding those connections.
A.C.T.U.A.L. is an operating system for coordinating decisions and work. It combines a shared operating contract, domain knowledge, human responsibilities and software capabilities. It does not replace Windows or your existing business applications. It establishes how the work around them is chosen, authorized, carried out, checked and maintained.
Explore the relationships the OS keeps together. Select a part to read how it works.
Review closes the loop. New evidence, a failed dependency or a changed purpose can change the next decision.
The ambition is a fundamental shift: from managing a collection of activities to maintaining a connected, challengeable account of what matters, what is being done and what the evidence supports.
Existing staff, tools and partners remain part of the answer. A recommendation should explain the gap it closes, the effort it creates and why the chosen approach fits. Sometimes the right next step is a simpler process, not another purchase.
“Not sure” is a valid starting point. An unknown becomes a question, an investigation or an explicit limit. It does not quietly become a positive assessment because someone needs a green dashboard.
A control that needs daily attention from someone available once a month is not a workable arrangement. Staffing, skills, fatigue, cost and maintenance effort belong in the design from the beginning.
Start with what the operation needs and what evidence establishes. Map applicable obligations to those facts. A changing framework changes the mapping; it should not erase the business’s operating history or redefine unsupported claims as true.
Security depends on the rest of the business: who has access, which tools you pay for, where AI touches data, whether systems can recover and who owns the next decision. The capability atlas brings those relationships into one explorable map.
Select a tile for the practical question, failure it addresses, evidence to look for and accountable role. This is a capability reference, not a live assessment or a list of features enabled in every deployment.
A paid license is not proof that protection is configured. Check the features you already have, verify the result, then consider retiring duplicate tools. The right recommendation can mean buying less software.
Different people need different answers. The shared value is knowing what matters, what to do next, who is responsible and what can actually be demonstrated. These are intended applications of the model; the available delivery and software scope is agreed for each engagement.
You need your business to keep working, without becoming a full-time security administrator.
Start with the few dependencies that could stop trading: email, payments, customer data, recovery and key suppliers. Agree a realistic survival floor and who maintains it.
A prioritized plan, visible gaps and an operating burden your team can sustain.
You need to know what to fund, what to accept and what remains unresolved.
Connect investment to business outcomes. Ask which result is supported, for which entity and period, and which critical dependency could undermine it.
Decision records and evidence with clear boundaries, rather than an unexplained score.
Your teams already have systems and expertise. The gaps often sit between them.
Join technical tasks to business priorities, dependencies, access decisions and acceptance tests. Preserve who owns the next step when work crosses a team or supplier boundary.
Shared context, clearer responsibilities and fewer repeated discovery requests.
A convincing answer does not tell you whether an AI workflow is useful, safe or authorized.
Define the intended task, permitted data and actions, human approval, failure handling and how results will be checked. Revisit the decision when the model or workflow changes.
A bounded trial and an explicit basis for expanding, changing or stopping it.
Advice loses value when implementation starts from a different understanding.
Work from the agreed purpose, evidence, authority and acceptance criteria. Bring in specialists where the problem exceeds your competence; retain the record when responsibility changes.
A clearer brief, traceable handovers and a shared basis for reviewing the work.
The same questions apply to personal accounts, shared devices and the ability to recover access.
Understand what is important, who can access it and who can help. Use plain-language guidance and proportionate steps instead of an enterprise checklist.
A practical starting point and clear ownership. Personal-use delivery and software availability must be confirmed separately.
Growing organizations add sites, entities, jurisdictions and specialist teams. The discipline stays the same; evidence and acceptance remain specific to the relevant scope.
This is where the idea becomes concrete. A backup tool is one component. The operating question includes people, access, payments, recovery and the decision to resume service. Expand a step to follow the work.
Illustrative scenario—not a measured customer outcome or a demonstration of enabled automation.
The business owner identifies the order process, acceptable interruption and essential records. The team records what is known, what is assumed and what remains uncertain.
What carries forward: A scoped outcome and an owner who can accept it.
Trace identity, hosting, payment processing, supplier connections, devices and the people who can restore access. A backup is not sufficient if the only administrator is unavailable or the payment service cannot reconnect.
What carries forward: A dependency picture with the consequential gaps visible.
Compare options such as improving existing recovery, adding a fallback or using specialist support. Include costs, available skills, operating hours and maintenance work. Record the reasoning and what would make the decision change.
What carries forward: A decision that explains its trade-offs and assumptions.
Assign configuration, access, recovery and training work. Define who can change production, who must approve it and how to stop or recover from a failed change. People and tools work within those boundaries.
What carries forward: Owned actions, visible handoffs and acceptance criteria.
Run an agreed restoration exercise. Record what was restored, how long it took, whether orders could be processed and which dependencies failed. A successful backup message alone does not answer these questions.
What carries forward: Evidence of the tested result, with its date, scope and unresolved gaps.
Agree the next exercise and the conditions that trigger earlier review: a new supplier, a changed system, lost access, staff turnover or ageing evidence. Preserve the previous result without treating it as permanent assurance.
What carries forward: A maintained arrangement, rather than a report that gets filed away.
Each result keeps its context. New evidence can change the next decision. A failed dependency can reopen work. A changed purpose can require a different strategy.
The A.C.T.U.A.L. overview introduces the operating system, System Library and Truth Engine: how work is organized and how its results are checked.
This earlier introduction explains the core ideas. The text below distinguishes the operating approach from software still in development.
See how the pieces connect ↓Choose the area that needs attention. Use the shared operating model to organize the work. Check evidence through the Truth Engine and use the result to decide what happens next.
Security · IT · AI · Vendors
Physical operations · Governance
Outcome · Owner · Authority
People · Tools · Actions
Sources · Evidence · Freshness
State · Record · Review
Start with an agreed piece of work and the tools your business already uses. Your people and service partners carry it out, with clear responsibility and a plan to check the outcome. QUONlab is the developing software workspace for this approach.
Explore practical support →A.C.T.U.A.L. connects business-aligned security strategy with the people, technology and evidence needed to carry it out. The revised model explains how that works beyond the software: understand the purpose, use the system, fit the work to your environment and keep adapting.
What are you trying to achieve? What could stop you? Connect the outcome to dependencies, consequences, resources and the person who can make the decision.
A clear purpose and boundaries.Use the operating model to organize questions, options, responsibilities and evidence. AI and tools can assist within declared authority; their output is not automatically proof.
Decisions and work you can trace.Bring together existing staff, service partners and specialists. Configure, test and hand over the arrangement in the actual environment, including physical dependencies and the effort people can sustain.
An owned, tested operating arrangement.Maintain the work, test recovery, review evidence and revisit decisions when people, tools, suppliers or conditions change. An earlier success cannot establish that everything still works today.
Current evidence and accountable follow-up.These four layers describe how A.C.T.U.A.L. is applied. They complement the System Library → Operating System → Truth Engine working view; they do not replace the architecture or its evidence rules.
The Business Security Executive function connects operating priorities, investment and risk decisions. Existing leaders can perform this function; the title alone does not grant authority.
The Forward Deployed Security Engineer function translates the strategy into practical work alongside your team. Specialist, fractional or existing staff support is chosen for the situation; a dedicated engineer is not always needed.
People and tools may perform the work, but a named human remains accountable for accepting the result. Consensus between AI agents, a completed task or a vendor statement is not independent verification.
Keep relevant evidence connected so teams do not repeat the same discovery for security, AI, suppliers and leadership reporting. Reuse applies only where the evidence supports the same fact for the relevant entity, environment and time. Proof from one business or system cannot silently establish another’s result.
The evolved design describes three deployment boundaries. Choose the arrangement around collaboration, data control and field access—not a requirement to send everything to the cloud. Availability and supported controls must be confirmed for the chosen deployment.
Teams and assigned specialists coordinate work with role-separated preparation and owner approval. Shared access must preserve responsibility and scope.
Local records and local AI processing on customer-controlled hardware, with explicit rules for information leaving the environment. Local hosting still needs secure operation.
Offline and manual reviews, controlled handoffs and separately governed recovery readiness. Keep raw credentials and recovery secrets out of ordinary evidence records.
The Truth Engine observes and qualifies evidence. People, agents and tools carry out authorized work through separate boundaries. Accepting a risk does not turn a failed control into a passing one.
A.C.T.U.A.L. is QUONtech’s operating system for running connected work and establishing what was true within a defined scope and time.
It starts with your situation: the outcome you need, your dependencies, your people, your physical environment and what you can sustain. The answer may involve your existing tools, specialist help, a different provider, or no additional purchase.
The OS defines the rules for ownership, authority, evidence and review. People and tools carry out the work within those rules. Buying a tool or completing a task does not, by itself, prove that the intended result was achieved.
These examples show how the approach can guide an engagement. They are illustrative arrangements, not measured customer outcomes or demonstrations of automated software.
The operations lead agrees which order process must recover and within what time. IT tests restoration, security reviews access and the business owner accepts the observed result. Record what was restored, elapsed time, missing dependencies and the next test date. A backup-success notification is a signal to inspect, not proof that orders can resume.
The service lead chooses a narrow task: draft replies for a person to approve. IT and security define which data the AI may use; governance names who may authorize the trial. Review a scoped sample for useful answers, inappropriate disclosure and handoff failures. Record gaps and revisit the decision when the model, data or workflow changes.
The process owner identifies the customer work that depends on the supplier. Procurement, IT and security agree responsibilities for migration, access removal and continuity. A dated test supports the defined handover; a supplier questionnaire remains a claim until supported. Leadership can see unresolved dependencies before accepting the change.
These are the principles behind the name. They guide how the system should work at every scale.
Personal, business and practitioner views use the same underlying facts, with a scope and language that fit.
Devices, locations, suppliers, people and the effort you can sustain belong in every decision.
Keep assertions, artifacts and observed results distinct. Show the evidence and its limits.
Start with a practical question. Design arrangements people can follow without risky workarounds.
Engineers and AI can prepare the work. Acceptance and consequential decisions stay with an authorized human.
Revisit the result when tools, people, dependencies or conditions change. Earlier success is not permanent proof.
The Truth Engine is the model for evaluating evidence about a specific safeguard or operating requirement: what it supports, who is accountable and how long the conclusion remains current. The states below describe that model. A result recorded in the developing workspace is a user report, not an independently verified control assessment or an automatic PASS.
A claim says something is true. A signal, such as an outage alert or vendor notice, tells us where to investigate. Proof must support the specific fact under review. A self-report or uploaded file alone cannot earn a PASS.
Old evidence cannot support a permanent green light. Freshness, changed conditions and disconnected sources require the state to be reconsidered.
A result for one system, site or date does not automatically cover another. Every claim needs its evidence, boundaries, timing and accountable acceptance.
Illustrative example: an action log proves an action occurred. Verification must establish the particular access condition being claimed.
Qualifying, current evidence supports the defined condition.
PASSThe model requires review as evidence ages or a supporting source goes offline.
PARTIALWhen the allowed partial period ends, the condition no longer remains partly proven.
FAILA new check supplies new evidence. Reassessment follows the defined acceptance rules; completing a task does not automatically restore PASS.
Illustrative expiry path in the reference model. Qualifying negative evidence can trigger FAIL immediately. Timing depends on the evidence class and scope; this is not a claim of currently enabled automation.
In place and supported by qualifying, current evidence.
Partly proven, evidence aging or a supporting integration offline.
Not proven, invalidated or no longer supported by qualifying evidence.
The model also distinguishes NOT-ASSESSED, justified NOT-APPLICABLE and RETIRED. Unknown is never silently treated as satisfied.
The record should make it possible to explain what operated, what failed, what was known and who owned it at a point in time. This is bounded operational evidence, not a guarantee that no incident can happen.
Scope systems apply the same operating rules to different domains. Primary systems establish domain evidence; hybrid systems also interpret it for a decision or event; overlays translate existing evidence for an audience or purpose.
The reference catalog below describes scope, not a promise that every module is enabled in every workspace. Manufacturing is included through a ratified amendment. Physical Security is a proposed addition whose module specification is pending.
The cybersecurity survival floor and the safeguards the business depends on.
Technology inventory, systems and dependencies.
Ownership, use and governance of AI across the business.
Boundaries on the information AI may access or disclose.
Third-party dependencies, access and exposure.
Production technology, remote vendor access, recovery and change. Excludes safety functions and safety-instrumented systems.
People, premises, equipment custody, utilities and physical dependencies.
New evidence under incident conditions, connected to the existing record.
Operating controls and governance reporting for the program.
Coordinated operation across multiple active scopes.
Diligence, inherited exposure, integration and transaction decisions.
Existing operating evidence translated into early-stage readiness.
Evidence for underwriting and renewal representations, without promises about premiums.
The operating picture translated into leadership and board decisions.
Evidence is reused only where it supports the same fact within the relevant boundary. A passing test at one location does not prove another location.
The purpose is to remove access the person should no longer hold while keeping the business running. Closing a ticket alone cannot prove that happened.
This example explains the operating model. It is not a demonstration of a currently enabled automated workflow.
Identify the accounts, devices, physical access and vendor systems involved, with a responsible owner.
Assign the right people or tools. Track dependencies, blocked actions and exceptions.
Collect qualifying evidence from the relevant systems. A request to revoke access is different from evidence that access was revoked.
Keep the dated result and its limits. Reuse it for the relevant IT, security or governance claims and flag anything unresolved.
Compliance is a separate overlay on the operating evidence. It does not rewrite the underlying state or turn missing proof into a PASS.
The developing model calls for applicability to be established before mapping: which entity, activity, jurisdiction, data or contract creates the obligation, and who reviews that conclusion. Legal requirements, contractual commitments and voluntary choices remain distinct.
Reuse is assessed requirement by requirement. Unresolved applicability and evidence gaps stay visible; the OS does not replace qualified legal or specialist judgment.
A named human accepts the result. Customer ownership does not remove a provider’s responsibility for the work it agreed to deliver.
Automation is an attributed actor with recorded boundaries. It cannot become the accountable human or approve evidence that does not support the claim.
The developing model calls for recommendations to include sources, alternatives, assumptions and a verification plan. The best fit may be a simpler approach or another provider.
For an agreed scope, the work should leave you with more than advice. These are the records and working arrangements the model calls for. Their format and delivery mode depend on the engagement.
The outcome, important dependencies, people and systems—plus the unknowns. Enough context to explain why a proposed action matters.
The selected approach, alternatives, assumptions, owner and review triggers. A future team can understand why the choice was made.
Responsibilities, authority, prerequisites and acceptance criteria. Unfinished work and blocked handoffs remain visible.
Sources, observations and dates tied to the specific claim. A recorded success is distinguishable from an independently checked condition.
A relevant fact can inform operations, supplier questions and leadership reporting without repeated intake, while preserving its original boundaries.
Maintenance, escalation, review dates and a workable handover. The continuing responsibility is explicit, including its cost and effort.
Those tools can contribute useful capabilities. A dashboard displays information. GRC tooling supports governance and obligations. An AI assistant can help interpret or perform work. A.C.T.U.A.L.’s organizing contract connects the purpose, authority, execution, evidence and continued review around an outcome. Which tools satisfy parts of that contract must be established for the actual implementation.
No. Your existing staff, suppliers and applications can remain. The model asks what capabilities the outcome requires, where they already exist, where a gap remains and who will keep them working. Software is one delivery mode; a manual or assisted arrangement must preserve the same ownership and evidence discipline.
Agree the measures before the work starts: for example, tested recovery time, unresolved critical dependencies, time spent repeating evidence requests, failed handoffs or overdue reviews. Record a baseline and compare like-for-like results. These are candidate measures, not claimed savings or guaranteed improvements.
No. It can establish what evidence supports within a defined scope and time and make uncertainty visible. It cannot prove that no attacker exists, no future incident will occur or every obligation is satisfied. An applicable legal or specialist question still needs appropriately qualified judgment.
Begin with the part of the business that needs attention. Agree the outcome, boundaries, critical safeguards, responsibilities, evidence and review cadence. Expand when the first arrangement is operating reliably.
Describe the outcome you need and what is getting in the way. We can agree a useful scope before choosing tools or a delivery arrangement.
Discuss A.C.T.U.A.L. →Work with QUONtech on scope, existing tools, integrations, expertise, ownership and acceptance.
Explore consulting →Use internal people, specialist partners or fractional leadership where the work calls for it.
Explore fractional leadership →No. The specification allows manual, assisted, platform and enterprise delivery. The same discipline for scope, evidence, ownership and review applies. The delivery mode and its limitations must be explicit.
Ask for the implementation declaration for your deployment: which requirements are specified, implemented, tested, enabled and operationally monitored; which scopes and integrations are active; and what coverage, data handling and limitations apply.
Consulting, implementation and fractional leadership are available through QUONtech by agreed scope. The A.C.T.U.A.L. software workspace in QUONlab is still in development and public access is not open. Supporting records and reported results need review: they do not, by themselves, establish independently verified assurance. We will agree what evidence is needed and who reviews it for your engagement.
Tell us what needs to work better. We will help define a practical starting scope and what success must demonstrate.
Talk about your operating reality →Public explanation updated October 23, 2026 with the 52-element capability atlas and six operating commitments, alongside the A.C.T.U.A.L. Operating System whitepaper v1.5 Review, Revision 2 (October 3, 2026), the reference model and development documentation reviewed October 18. The atlas describes capability contracts; it does not establish that every described automation or deployment mode is enabled. The expanded reference remains proposed; the established baseline still applies. Service delivery, specification requirements and deployed software capabilities are distinct.