Skip to content
LorasisLorasis

Building toward the cybersecurity Trust Operating System

Before machines act, check the evidence and authority.

Lorasis is building the cybersecurity Trust Operating System for consequential machine action. This is vision language, not a claim that the full system is shipped.

Request a Technical Briefing
Explore a Bounded ValidationOne workflow, not an estate

Long-term direction. Bounded current foundation.

One workflow recorded as a traceA stepped trace runs left to right across a ruled measurement field, rising at the authority gate and continuing through bounded action to a checkable record. Two segments are drawn broken, marking an unsupported source and an unknown observation.declared scoperuntime evidenceunsupported sourceexplicit authoritybounded actioncheckable recordunknown remains unknownfig. 00 — one workflow, recorded
Solid trace: what the declared scope covers. Broken trace: what is unsupported or unknown and stays visible as such.

The accountable gap

A policy is necessary. It is not proof of runtime reality.

Policies, dashboards, control-plane acknowledgements, disconnected logs and system self-reporting are all useful. None of them alone establishes the complete runtime reality of a consequential automated workflow. Read one workflow across four lanes and the gap becomes visible.

Four accounts of one workflowFour measurement lanes run across the same four workflow moments: scope, authority, execution and outcome. Intent and self-report run continuously, the independently observed trace is drawn solid only where evidence exists and then falls away, and the unknown lane is hatched throughout.scopeauthorityexecutionoutcomeWhat should happendeclared intentWhat the system reportsself-attestedWhat was independently observedruntime evidenceevidence endsWhat remains unknownunevidencedthe gap between the lanesfig. 01 — one workflow, four accounts
Which workflow is in scope?
Declared scope is recorded with the evidence it covers.
Anything outside that boundary stays marked as excluded.
Who authorised the action?
Authority is recorded at the point the action was permitted.
Where the authority path is not covered, it is unsupported.
What actually ran?
Runtime evidence is collected on the paths the workflow uses.
Uncovered paths are recorded as unsupported, not as a pass.
What was observed afterwards?
Observation comes from a vantage point outside the acting system.
Where observation is not established, the outcome is unresolved.

The bounded evidence model

Evidence is only credible when it shows its own boundary.

A record that cannot state its scope, its source, its freshness, its exclusions and its unresolved unknowns is a summary, not evidence. The relationship below is the conceptual model; the maturity status beside each stage says how far it is established today.

The bounded evidence chainSix stages connected left to right from declared scope to checkable record. The authority stage is drawn as a gated square, and the links after executed outcome are broken to show that end-to-end delivery is not claimed.Declaredscope01Runtimeevidence02Explicitauthority03Executedoutcome04Independentobservation05Checkablerecord06current foundation in bounded environmentsnot claimed end to endfig. 02 — bounded evidence chain
  1. 01

    Declared scope

    What the record covers, and what it deliberately excludes.

    Current foundation

  2. 02

    Runtime evidence

    Collected from the paths a workflow actually uses.

    Current foundation

  3. 03

    Explicit authority

    Deterministic policy or a named authorised person decides.

    NOT SHIPPED

  4. 04

    Executed outcome

    Only the authorised action, inside its declared limits.

    NOT SHIPPED

  5. 05

    Independent observation

    Not the acting system's own account of itself.

    Proposed customer validation

  6. 06

    Checkable record

    Records a reviewer can check within a stated scope.

    Current foundation

boundary
what the record covers
source
where the evidence came from
freshness
when it was established
exclusions
what was left out on purpose
unknowns
what could not be established

Conceptual relationship, not a claim that every stage is currently delivered end to end.

The enabling platform

REAP™

Runtime Enforcement and Attestation Platform

One platform, three movements: establish what actually ran, keep authority explicit, and make the resulting record checkable.

01

Establish what actually ran

Runtime evidence is collected from the paths a workflow actually uses, and anchored to a hardware-rooted point of reference.

Sense · Anchor

Sense: current foundation · Anchor: VISION

Sense: selected runtime-evidence paths. Shown in named, controlled internal workflows. Proof point being hardened. Not a production deployment and not an external demo. Anchor: hardware-rooted attestation and silicon-rooted paths. VISION. Intended path. Not current customer coverage.

02

Keep authority explicit

A proposed action is tested against deterministic policy, routed to the person or control holding authority, and carried out only within its declared limits.

Decide · Enforce

NOT SHIPPED

Deterministic policy and authorised humans retain decision authority; bounded customer-local action remains subject to release and validation gates.

03

Make the record checkable

What was seen to happen is recorded from a vantage point that is not the acting system's own account of itself, and issued as records a reviewer can check.

Observe · Prove

Proposed customer validation, on a current foundation

Independent observation and complete evidence-to-outcome linkage require customer validation. Provenant signed records cover named evidence slices; the broader end-to-end proof direction is not a current capability.

Product architecture, not a claim that every stage is currently available.

Where this matters

Governed artificial intelligence and automated operations

Can the organisation establish what a consequential automated workflow was intended to do, who authorised it, and what actually ran?

Operational resilience and critical operations

When a consequential action changes something, can its runtime reality be reconstructed afterwards?

Audit, assurance and internal review

Can a reviewer check the record independently, rather than accept a summary?

Evidence, authority and what a record can establish

Artificial intelligence may discover, explain and propose.

Deterministic controls and authorised humans decide.

The authority boundaryThree advisory inputs above a ruled boundary line feed a single decision below it. Nothing crosses the line implicitly; the crossing is drawn as one gated link.discoverexplainproposeadvisory — no effectauthority boundarydecisiondeterministic control or authorised personfig. 03 — authority boundary

Everything above the line informs a decision: what was found, how it was interpreted, what is being proposed. Everything below it is an act of authority. Nothing crosses that line implicitly, and no model signs, approves, deploys, contains, releases or enforces on its own account.

Provenant supports signed, hash-linked records for named evidence slices in bounded paths. Included records can be checked for integrity within their declared verification scope.

Signed and hash-linked records do not by themselves prove completeness, semantic correctness, absence of compromise, overall security, regulatory compliance or that an event occurred freshly.

Evidence states

verified
checked within declared scope
pending
expected, not yet available
excluded
outside the declared scope
unsupported
path not covered
stale
outside its freshness window
failed
a check did not pass
conflicting
two accounts disagree
unknown
nothing can be established

Unknown is a legitimate outcome and is never presented as a pass.

Regulatory contexts

Contexts a validation may be read against.

European Union Artificial Intelligence ActEU AI Act
May provide a governance or validation context for how an in-scope artificial-intelligence system is operated and overseen.
Digital Operational Resilience ActDORA
May provide a governance or validation context for operational resilience expectations in financial entities.
Network and Information Security Directive 2NIS2
May provide a governance or validation context for risk-management and reporting duties in covered sectors.

This is not a Lorasis certification or readiness claim. Applicability depends on the organisation, system, role, sector and jurisdiction.

Long-term vision

Lorasis is building the cybersecurity Trust Operating System for consequential machine action.

It is designed to help enterprises govern whether bounded actions across critical infrastructure may proceed, and to make what was intended, authorised, executed and observed independently checkable.

Long-term vision — direction, not a currently complete product

Start with one consequential workflow.

Explore a bounded validation around one in-scope artificial-intelligence or automated workflow and the evidence needed for a real compliance, governance, risk, security or audit decision.

A bounded validation is not

  • a product name
  • a deployment commitment
  • a compliance assessment
  • a certification
  • a claim of regulatory readiness

20–2,000 characters. Do not include secrets.

Contact details are not sent to analytics or placed in browser storage.

Lorasis Solutions, S.L

Tres Cantos

Spain

Phone: +34 636 895 146