Skip to main content

The Architecture

A control layer for the enterprise you already operate.

NEED2KNOW™ sits between enterprise context and the systems that present or process information.

Identity, application, data and security systems remain authoritative. CUDE coordinates what becomes visible for each interaction.

Explore the architectureRequest an architecture briefing

Enterprise environment

Existing systems stay in place

  1. Context in

    Identity · Task · Contract · Asset · Risk

  2. NEED2KNOW

    Resolve context · Evaluate policy · Issue decision

  3. Decision out

    Interface · API · Data · Renderer · AI workflow

Information remains in the connected system
Authoritative enterprise context enters NEED2KNOW. A structured decision returns to a connected enforcement point while information remains in the connected system.

Where it sits

Where NEED2KNOW sits.

It introduces a decision path between the context an organisation already holds and the places where information is presented or used.

Enterprise architecture position

Context in · Structured decision out

  1. 01

    Participants

    Employees · Partners · Contractors · AI systems · Services

    The people and systems involved in an approved interaction.

  2. 02

    Enterprise context

    Identity · Role · Task · Contract · Asset · Risk

    Supplied by the identity, business, application, data and security systems that remain authoritative.

  3. 03

    NEED2KNOW™

    Policy · Visibility · Usage · Evidence

    Resolves the relevant context and returns a structured decision.

  4. 04

    Enforcement points

    Applications · APIs · Data services · Renderers · AI workflows

    Translate the decision into controls the connected system supports.

  5. 05

    Governed interaction

    Approved information and permitted actions

    Information remains in the connected application and data path.

Participants initiate an interaction. Existing enterprise systems supply authoritative context to NEED2KNOW, which returns a structured decision to connected enforcement points. The connected system then presents approved information and permitted actions.

What stays authoritative

Existing systems remain authoritative.

NEED2KNOW resolves the context required for a decision without becoming the system of record for identity, work or information.

Identity systems
Remains authoritative forAuthenticated identity and participant attributes
Contributes to the decisionWho is participating
Business systems
Remains authoritative forProjects, tasks, contracts and workflows
Contributes to the decisionWhy the interaction is taking place
Applications and data
Remains authoritative forInformation, asset structure and presentation
Contributes to the decisionWhat can be controlled and where it is enforced
Security systems
Remains authoritative forRisk signals and monitoring context
Contributes to the decisionCurrent conditions and relevant events

NEED2KNOW coordinates the visibility decision across these sources.

Where the decision is made

The control plane produces the decision.

For each request, it brings together relevant enterprise context and applicable policy, then returns a contract the connected system can enforce.

Decision path

One request · One enforceable result

Request context

Participant · Task · Asset · Current condition

Applicable policy

Visibility rules · Usage conditions

Visibility control plane

Decision boundary
  1. 01

    Resolve

    Assemble the context required for this request.

  2. 02

    Evaluate

    Apply the policy relevant to the interaction.

  3. 03

    Issue

    Return a result the connected system can enforce.

Decision contract

  • Visibility
  • Usage
  • Conditions
  • Evidence

Enforcement plane

Applied where work occurs

  • Interface
  • API
  • Data
  • Renderer
  • AI workflow

Governed interaction

Request context and applicable policy enter the visibility control plane. The control plane resolves context, evaluates policy and issues a structured decision. Connected systems enforce that decision where work occurs.

Where the decision lands

Enforcement stays where the work happens.

The same decision contract is translated into controls the connected application, service or workflow already understands.

Structured decision

Shared contract

  • Visibility
  • Usage
  • Conditions
  • Evidence
Applied by connected systems

  • Application interface

    Render only approved fields, sections and controls.

  • API

    Filter the response and permit approved operations.

  • Data service

    Project approved rows, columns or objects.

  • Model renderer

    Expose approved components, layers and tools.

  • AI workflow

    Bound retrieval context, tools and outputs.

Shared policy · Asset-local enforcement · Governed interaction

A structured decision carries visibility, usage, condition and evidence fields. Application interfaces, APIs, data services, model renderers and AI workflows translate those fields into controls that fit their information structure.

Working with asset structure

Precision begins with the structure a system exposes.

Policy can only govern elements the connected system can identify and control.

Exposed structure → enforceable control points
Documents
System can identifySections · Attachments · Metadata
Policy can governVisibility · Redaction · Copy · Export
Engineering models
System can identifyComponents · Assemblies · Layers · Geometry
Policy can governView · Measure · Annotate · Export
Structured data
System can identifyTables · Rows · Columns · Fields
Policy can governQuery · Filter · Reveal · Export
AI workflows
System can identifySources · Context · Tools · Outputs
Policy can governRetrieve · Invoke · Retain · Return
Software environments
System can identifyRepositories · Modules · Branches · Builds
Policy can governRead · Change · Build · Release
Component-level policy requires the connected system to expose those components as controllable elements.

What an integration involves

Connect context. Return decisions.

Each integration defines the request, context, decision and event exchange required by one connected workflow.

Shared decision service

NEED2KNOW™

Resolves context, evaluates policy and returns a structured decision.

  • Identity

    SSO · MFA · Federation · Service identity

    Participant attributes

  • Applications

    Engineering · Collaboration · Business systems · Portals

    Requests and decisions

  • Data

    Documents · Databases · Object stores · Repositories

    Asset context and scope

  • AI

    Model gateways · Retrieval pipelines · Agents · Tools

    Governed context and actions

  • Security operations

    Zero Trust · DLP · SIEM · Security analytics

    Risk signals and relevant events
Each connected workflow defines the context it supplies, the decision it receives and any relevant events returned for monitoring or review.

Where it runs

Deploy within the organisation’s operating boundary.

These are discovery patterns, not deployment commitments. Exact placement, ownership and data flow require technical verification for the defined interaction.

Cloud

For environments operating primarily across cloud applications and data platforms.

Illustrative control-plane boundary

Approved cloud environment

Hybrid

For organisations working across cloud and internal infrastructure.

Illustrative control-plane boundary

Selected cloud or internal boundary

Private or on-premises

For organisations requiring greater control over processing and operation.

Illustrative control-plane boundary

Organisation-controlled environment

Sovereign

For environments with defined residency, administration or national-control requirements.

Illustrative control-plane boundary

Approved sovereign boundary

Placement to verify

Scroll horizontally to compare every model.

Illustrative deployment considerations to verify for cloud, hybrid, private or on-premises, and sovereign environments.
Architecture decisionCloudHybridPrivate or on-premisesSovereign
Control-plane locationApproved cloud environmentSelected cloud or internal boundaryOrganisation-controlled environmentApproved sovereign boundary
Decision-processing locationAgreed cloud service boundaryPlaced for latency and boundary needsInternal processing boundaryRequired control jurisdiction
Enforcement locationConnected cloud servicesCloud and internal systemsInternal applications, services and gatewaysApproved systems within that boundary
Data-flow boundaryDefined context and decision interfacesExplicit cross-boundary routesEnterprise-controlled interfacesResidency and transfer constraints
Operational ownerAgreed cloud operating teamShared platform and infrastructure ownershipOrganisation operating teamAuthorised operating entity

What it has to meet

Visibility decisions must meet enterprise operating requirements.

The architecture should follow the needs of the connected workflow, not impose one operating pattern on every organisation.

Operating requirement

Performance

  • Response time
  • Availability

Match the decision path to the workflow’s tolerance for latency and interruption.

Operating requirement

Continuity

  • Resilience
  • Defined failure behaviour

Define how the interaction behaves when context or decision services are unavailable.

Operating requirement

Governance

  • Policy consistency
  • Administrative control

Keep policy ownership, change authority and expected decision behaviour explicit.

Operating requirement

Assurance

  • Data residency
  • Observability

Align processing boundaries and operational evidence with organisational obligations.

How to begin

Start with one defined interaction.

A bounded use case makes the system boundary, decision location and integration work concrete.

  1. Phase 01

    Interaction

    • Identify the participant
    • Define the approved task
  2. Phase 02

    Information

    • Identify the information asset
    • Describe the current exposure problem
  3. Phase 03

    Enforcement

    • Locate the application or workflow
    • Define the enforcement point
  4. Phase 04

    Operating model

    • Identify the identity and policy sources
    • Establish the deployment boundary

Discovery output

Architecture brief

  • System boundary
  • Decision location
  • Integration scope
Request an architecture briefingSee How It Works