Skip to main content

How It Works

Visibility is calculated at runtime.

From decision request to governed view.

Inspect the Decision PipelineView the Architecture

Visibility decision pipeline

  1. Connected System

  2. Decision Request

    Before a connected application presents information or permits an action, it sends a decision request to the Visibility Engine.

  3. Visibility Engine

    The engine evaluates the participant, requested action, information asset, approved task and current condition.

  4. Structured Decision

    The visibility engine returns a structured decision defining what to show, what to withhold, which actions to permit and when the decision should be reviewed.

  5. Enforcement Point

  6. Governed View

    Participants only see what they need to know for their approved tasks.

The runtime sequence

Visibility decisions are notthe same as access control.

Access control makes a decision at the point of entry. A visibility decision moves through a defined runtime sequence.

  1. 01

    Request

    A connected system asks what this participant may see or do.

  2. 02

    Resolve context

    Identity, task, asset and environmental information are gathered from authoritative systems.

  3. 03

    Identify policy

    The engine determines which rules apply to the request.

  4. 04

    Calculate visibility

    The permitted information boundary is established.

  5. 05

    Determine usage

    The actions available within that boundary are calculated separately.

  6. 06

    Return the decision

    The engine sends the result to the connected system.

  7. 07

    Enforce

    The application, service or workflow applies the decision.

  8. 08

    Record

    The decision and relevant interaction events are captured.

  9. 09

    Re-evaluate

    A new decision can be requested when the underlying conditions change.

A visibility decision runs as a repeating loop of 9 stages, from a request by a connected system through to re-evaluation when the underlying conditions change.

The visibility engine sits in the decision path. The connected system remains in the information and interaction path.

Every decision starts here

Every decision begins with a specific request.

The engine does not decide whether a participant should have general access in the abstract. It evaluates a particular action involving a particular resource under a defined set of conditions.

Decision Inputs

Subject
Supplier Engineer
Object
Turbine Housing
Action
Review & Annotate
Context
Project X
Policy
Contractual Permission
Risk
Approved Device

Runtime Question

What should this participant be able to see and do in this interaction?

What the engine draws on

The engine uses context already held by the enterprise.

The visibility engine does not invent the identity, task or business conditions behind a decision. It receives or resolves them through connected systems that remain authoritative for enterprise context.

01

Identity context

Provided by identity and authentication systems.

  • authenticated identity
  • organisation
  • role
  • group membership
  • service or machine identity
02

Work context

Provided by project, workflow and business systems.

  • assigned task
  • project
  • contract
  • programme
  • approval status
  • business purpose
03

Environmental context

Provided by security and device systems.

  • device posture
  • location
  • time
  • network context
  • session state
  • current risk signals
04

Resource context

Provided by the application or asset system.

  • resource identifier
  • asset type
  • internal structure
  • classification
  • ownership
  • related metadata

The quality of the decision depends on the quality and availability of the context supplied to it.

How policy is applied

Policy is evaluated against the complete request.

The visibility engine evaluates who is participating, what they are doing, which resource is involved and which conditions are true. The result is not simply allow or deny.

Runtime policy evaluation

Complete request

Request context

Participant
Approved supplier
Task
Component validation
Resource
Turbine assembly
Contract
Active
Device
Managed

Policy 3.8

Evaluates the complete request

Governed result

Participation permitted.Visibility bounded.

Information available
Assigned component and approved manufacturing data
Actions available
View, rotate, measure and annotate
Outside task boundary
Hidden layers, copying and complete export
Decision remains valid
Until the task or contract changes
May participate

Allowed into the task does not mean allowed to see the whole asset.

What comes back

The result is a structured contract for the interaction.

The engine does not return visibility alone. It returns the information boundary, permitted actions, applicable conditions and evidence required by the connected system.

Decision contract

VD-20481

Subject
Component TH-204
Policy version
3.8
01

Visibility

The information boundary for this interaction.

Show

  • Component TH-204
  • Manufacturing tolerances
  • Approved material data

Withhold

  • Adjacent assemblies
  • Internal design rationale
  • Commercial metadata
02

Usage

The actions available inside that boundary.

Permit

  • View
  • Rotate
  • Measure
  • Annotate

Restrict

  • Reveal hidden layers
  • Copy unrelated content
  • Export completed assembly
03

Conditions

All must remain true.

  • Task remains active
  • Contract remains valid
  • Device remains compliant
  • Location remains approved
04

Lifecycle

How long the decision stands.

  • Valid for current session
  • Re-evaluate on sensitive action
  • Expire on task completion
Requested
14:28:06
Enforced
14:28:06
Evidence
Recorded

Who enforces it

The visibility engine decides. The connected system enforces.

A decision only matters when it is enforced.

Turbine Housing

Component TH-204

Approved component geometry and manufacturing information.

Exploded technical view of turbine housing component TH-204
Component
TH-204
Material
Inconel 718
Tolerance
+0.02 mm
Visibility scope
Component review
Interactive examples showing how a connected system enforces visibility decisions across its interface, APIs, queries, rendering, AI and user actions.

How enforcement adapts

Different assets expose different control points.

A document, engineering model, dataset and AI workflow do not expose information in the same way. The decision model remains consistent. The enforcement method changes with the structure of the asset.

CAD

  • Component-level visibility
  • Geometry access
  • Export governance
  • Layer restrictions
  • Measurement permissions
  • Controlled interaction
Select an asset type to compare the control points exposed by its internal structure.

When it changes

A valid decision can later change.

Context changes. Risk changes. Tasks complete. Policies evolve. When that happens, the visibility engine can issue a new decision and the view is updated.

Re-evaluation triggers

  • Participant requests action outside the approved scope.
  • Task is updated or marked complete.
  • Contract expires or terms are updated.
  • Device posture becomes non-compliant.
  • Policy rules are revised or added.
  • Risk posture or environment changes.
The decision lifecycle progresses from request through enforcement, changing conditions, re-evaluation and an updated decision.

The Next Control Layer

The future of collaboration is not simply deciding who can enter.

It is deciding what becomes visible once they do.

View the ArchitectureRequest a Briefing