System Library
Security · IT · AI · Vendors
Physical operations · Governance
QUONTECH / OUR OPERATING SYSTEM
A.C.T.U.A.L.
Our operating system
for your business.
A shared way to decide what needs doing, coordinate the people and tools doing it, and verify the result.
A.C.T.U.A.L. combines an operating model, a library of business scopes and a software workspace in QUONlab. It connects objectives, responsibilities, actions and evidence across security, IT, AI and governance, so the work can be followed from the first decision to the next review.
QUONlab is the platform entry point. Account access and enabled capabilities depend on your workspace.
WATCH / THE BIG PICTURE
See the system.
Then explore the parts.
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 existing introduction predates the proposed v1.5 reference. The explanation below covers the newer direction.
See how the pieces connect ↓WHAT IT IS / HOW IT FITS TOGETHER
One operating system. Three connected parts.
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.
Operating System
Outcome · Owner · Authority
People · Tools · Actions
Truth Engine
Sources · Evidence · Freshness
State · Record · Review
Review the result. Adjust the arrangement. Recheck when things change.
Where you use it
QUONlab is the software entry point. Your people and service partners carry out agreed work, using the tools appropriate to your business. The OS keeps purpose, responsibility and proof connected.
Open QUONlab ↗THE BUSINESS COMES FIRST
The right arrangement for your reality.
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.
FROM PRINCIPLE TO EVERYDAY OPERATION
Four parts that must work together.
A specification, a usable tool, an implementation in your business and continuing operation each have a distinct role. The proposed v1.5 reference makes these responsibilities explicit.
Principles & framework
The shared contract: purpose, ownership, decision rules, evidence and the limits of every claim.
What makes a conclusion trustworthy?OS & capabilities
The interfaces, connections and records that make the model usable. Each implementation must state what it actually supports.
What can people accomplish here?Implementation
Agree scope, responsibilities, authority, existing tools, expertise and how results will be accepted.
Who does what, for this business?Continuing operation
Use the arrangement, review evidence, handle exceptions and adjust as circumstances change.
Is it still delivering the outcome?THE SIX OPERATING FUNCTIONS
A shared rhythm across every scope.
These six functions connect the first business question to ongoing assurance. They are revisited as the work and the organization change.
Alignment
Agree the outcome, the business context, dependencies, scope and accountable owner.
Control Readiness
Define what must be in place, what would count as evidence and which failures are critical.
Trust & Governance
Set decision rights, authority, approvals and the boundaries for people and automation.
Use in Real Operations
Make the work part of daily operation, with actions, dependencies and exceptions visible.
Adoption & Transition
Help people take ownership and move to the new arrangement without breaking the business.
Lifecycle Assurance
Recheck on a schedule and on change. Refresh proof, revisit decisions and retire work properly.
THE TRUTH ENGINE
“Done” is a task status.
“Proven” needs evidence.
The Truth Engine evaluates evidence about a specific safeguard or operating requirement. It records what the evidence supports, who is accountable and how long the conclusion remains current. It observes; it does not execute the work or recommend products.
Source matters
A self-report helps identify the work. It cannot earn a PASS. Artifacts, independent corroboration and authenticated integrations provide different levels of proof.
Proof has a shelf life
Old evidence cannot support a permanent green light. Freshness, changed conditions and disconnected sources require the state to be reconsidered.
Scope stays visible
A result for one system, site or date does not automatically cover another. Every claim needs its evidence, boundaries, timing and accountable acceptance.
“Access was removed.”A statement starts the investigation.
→Inspect the evidence.Which account? Which source? What date?
→Record a bounded result.State, scope, owner and next review.
Illustrative example: an action log proves an action occurred. Verification must establish the particular access condition being claimed.
PASS
In place and supported by qualifying, current evidence.
PARTIAL
Partly proven, evidence aging or a supporting integration offline.
FAIL
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.
Post Security: reconstruct reality later.
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.
THE A.C.T.U.A.L. SYSTEM LIBRARY
Start with one area. Keep the evidence connected.
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.
Secure SMB
The cybersecurity survival floor and the safeguards the business depends on.
IT Foundation
Technology inventory, systems and dependencies.
A.C.T.U.A.L. AI
Ownership, use and governance of AI across the business.
AI DLP
Boundaries on the information AI may access or disclose.
Vendor Trust / Supply Chain
Third-party dependencies, access and exposure.
Manufacturing
Production technology, remote vendor access, recovery and change. Excludes safety functions and safety-instrumented systems.
Physical Security
People, premises, equipment custody, utilities and physical dependencies.
Incident Response
New evidence under incident conditions, connected to the existing record.
GRC
Operating controls and governance reporting for the program.
Program Operations
Coordinated operation across multiple active scopes.
M&A
Diligence, inherited exposure, integration and transaction decisions.
Startup
Existing operating evidence translated into early-stage readiness.
Cyberinsurance
Evidence for underwriting and renewal representations, without promises about premiums.
For Boards
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.
AN ILLUSTRATIVE EXAMPLE
A departing employee.
One connected piece of work.
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.
- Define the boundary.
Identify the accounts, devices, physical access and vendor systems involved, with a responsible owner.
- Authorize and carry out the work.
Assign the right people or tools. Track dependencies, blocked actions and exceptions.
- Check what actually changed.
Collect qualifying evidence from the relevant systems. A request to revoke access is different from evidence that access was revoked.
- Record, reuse and review.
Keep the dated result and its limits. Reuse it for the relevant IT, security or governance claims and flag anything unresolved.
COMPLIANCE HAS ITS PLACE
Map obligations to reality.
Compliance is a separate overlay on the operating evidence. It does not rewrite the underlying state or turn missing proof into a PASS.
The proposed v1.5 model requires 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.
PEOPLE, TOOLS AND ACCOUNTABILITY
Clear responsibility is part of the system.
Your business owns its truth
A named human accepts the result. Customer ownership does not remove a provider’s responsibility for the work it agreed to deliver.
AI works within authority
Automation is an attributed actor with recorded boundaries. It cannot become the accountable human or approve evidence that does not support the claim.
Advice must earn its place
The tool may recommend an arrangement with sources, alternatives, assumptions and a verification plan. The best fit may be a simpler approach or another provider.
PUT IT TO WORK
One useful scope. A clear owner. A result you can check.
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.
Explore the OS
Open QUONlab to access the platform. Your account and workspace determine which services and capabilities are available.
Open A.C.T.U.A.L. in QUONlab ↗Establish your arrangement
Work with QUONtech on scope, existing tools, integrations, expertise, ownership and acceptance.
Explore consulting →Operate with the right help
Use internal people, specialist partners or fractional leadership where the work calls for it.
Explore fractional leadership →Does A.C.T.U.A.L. require a particular software product?
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.
How do I know which capabilities are actually available?
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.
What does the new v1.5 paper change?
The October 3, 2026 reference is marked PROPOSED. It expands the explanation of connected work, implementation responsibilities, recommendation discipline and physical context. It retains v1.4 as the locked baseline until ratification. This page explains that direction; it does not assert v1.5 software conformance or that every specified capability is live.
Make the next step clear.
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 →Based on the A.C.T.U.A.L. Operating System Baseline Specification, proposed v1.5, October 3, 2026. Public explanation reviewed October 7, 2026. Specification requirements and deployed capabilities are distinct.