Architecture Overview¶

Status: Draft

Purpose¶

This document presents the high-level architecture of the Nivron platform.

It defines the primary products, their responsibilities, the operational boundaries between local and global capabilities, and the architectural principles that guide the evolution of the platform.

The goal of this page is to provide a stable architectural map before introducing the internal design of each product and subsystem.

Platform Summary¶

Nivron is an operational governance and orchestration platform designed to coordinate infrastructure operations across heterogeneous technologies.

The platform is organized around three primary products:

Nivron Manager — the local operational authority;
Nivron IQ — the platform intelligence and lifecycle governance layer;
Nivron SaaS — the global governance and cloud services layer.

These products are related, but they do not share the same operational role.

The Nivron Manager governs and executes operations inside the customer environment.

Nivron IQ provides intelligence about the health, lifecycle, compatibility and evolution of Nivron installations.

Nivron SaaS provides optional global coordination, multi-installation visibility and cloud-delivered capabilities.

flowchart TD
    USERS["Users, Systems and Operational Processes"]

    subgraph PLATFORM["Nivron Platform"]
        MANAGER["Nivron Manager<br/>Local Operational Authority"]
        IQ["Nivron IQ<br/>Platform Intelligence"]
        SAAS["Nivron SaaS<br/>Global Governance and Cloud Services"]
    end

    INFRA["Customer Infrastructure and Technology Platforms"]

    USERS --> MANAGER
    MANAGER --> INFRA

    MANAGER -. Optional platform telemetry .-> IQ
    MANAGER -. Optional synchronization .-> SAAS
    IQ -. Lifecycle and advisory information .-> MANAGER
    SAAS -. Global governance and cloud services .-> MANAGER

The platform is local-first.

A customer must be able to operate Nivron Manager without requiring a permanent dependency on Nivron SaaS or Nivron IQ.

Architectural Scope¶

The Nivron architecture is divided into three main layers.

flowchart TD
    PRODUCT["Product Architecture"]
    DOMAIN["Operational Domain Architecture"]
    FOUNDATION["Technical Foundations"]

    PRODUCT --> DOMAIN
    DOMAIN --> FOUNDATION

Product Architecture¶

Defines the responsibilities and boundaries of:

Nivron Manager;
Nivron IQ;
Nivron SaaS.

Operational Domain Architecture¶

Defines how Nivron governs and coordinates operations through:

Operational Brain;
Missions;
planning;
dispatch;
scheduling;
execution;
Skill Runtime;
Skills;
evidence and audit.

Technical Foundations¶

Defines the shared engineering foundations used to implement the products, including:

identity;
APIs;
data persistence;
platform framework;
observability;
security;
repository organization;
deployment architecture.

This separation prevents implementation details from becoming the public operational model of the platform.

Nivron Manager¶

Nivron Manager is the primary operational product of the platform.

It is deployed inside the customer environment and acts as the local authority for governance, orchestration, scheduling, execution, audit and evidence.

Nivron Manager is not a passive edge component.

It is a complete operational platform capable of functioning independently.

Its responsibilities include:

local administration;
identity and access control;
inventory and resource context;
policy evaluation;
approval coordination;
Mission lifecycle management;
planning;
scheduling;
dispatch;
execution;
Skill orchestration;
evidence retention;
audit;
local observability.

flowchart TD
    subgraph MANAGER["Nivron Manager"]
        PORTAL["Local Portal"]
        BRAIN["Operational Brain"]
        SCHEDULER["Scheduler"]
        EXECUTION["Mission Execution"]
        RUNTIME["Skill Runtime"]
        SERVICES["Local Platform Services"]
        DATA["Local Operational Data"]
    end

    USERS["Users and Systems"]
    SKILLS["Skills"]
    TARGETS["Infrastructure Platforms"]

    USERS --> PORTAL
    PORTAL --> BRAIN
    BRAIN --> SCHEDULER
    SCHEDULER --> EXECUTION
    EXECUTION --> RUNTIME
    RUNTIME --> SKILLS
    SKILLS --> TARGETS

    PORTAL --> SERVICES
    BRAIN --> DATA
    EXECUTION --> DATA
    SERVICES --> DATA

The local portal and the local control capabilities together form the operational authority of the environment.

Operational Brain¶

The Operational Brain is the decision and orchestration engine of Nivron Manager.

It transforms operational intent into governed Missions by combining:

identity;
organizational context;
inventory;
policy;
authorization;
approval;
operational knowledge;
execution capabilities.

Its primary internal domains are:

Context;
Governance;
Mission Control;
Mission Planner;
Mission Dispatch.

flowchart LR
    INTENT["Operational Intent"]
    CONTEXT["Context"]
    GOVERNANCE["Governance"]
    CONTROL["Mission Control"]
    PLANNER["Mission Planner"]
    DISPATCH["Mission Dispatch"]

    INTENT --> CONTEXT
    CONTEXT --> GOVERNANCE
    GOVERNANCE --> CONTROL
    CONTROL --> PLANNER
    PLANNER --> DISPATCH

The Operational Brain governs what must happen and under which controls.

It does not directly implement vendor-specific infrastructure operations.

Those operations are performed through the execution layer and Skills.

For the detailed model, see The Operational Brain.

Mission Architecture¶

A Mission is the governed representation of an operational objective.

It provides the stable model that connects intent, policy, planning, execution, verification and evidence.

flowchart TD
    REQUEST["Request"]
    MISSION["Governed Mission"]
    PLAN["Execution Plan"]
    SCHEDULE["Schedule"]
    EXECUTE["Execution"]
    VERIFY["Verification"]
    EVIDENCE["Evidence and Audit"]

    REQUEST --> MISSION
    MISSION --> PLAN
    PLAN --> SCHEDULE
    SCHEDULE --> EXECUTE
    EXECUTE --> VERIFY
    VERIFY --> EVIDENCE

A Mission is expected to define:

the requested outcome;
the initiating identity;
the organizational scope;
the target environment;
validated parameters;
applicable policy decisions;
approval requirements;
the execution strategy;
expected outputs;
verification criteria;
evidence requirements.

The Mission model separates the operational objective from the technical mechanism used to execute it.

Skill Architecture¶

Technology-specific execution knowledge is implemented through Skills.

A Skill encapsulates the logic required to interact with a technology, platform or operational domain.

Examples include Skills for:

Huawei;
NetApp;
VMware;
Linux;
Kubernetes;
Microsoft platforms;
cloud services;
future operational domains.

flowchart LR
    MISSION["Mission"]
    PLAN["Execution Plan"]
    RUNTIME["Skill Runtime"]
    SKILL["Skill"]
    TARGET["Target Technology"]
    RESULT["Structured Result"]

    MISSION --> PLAN
    PLAN --> RUNTIME
    RUNTIME --> SKILL
    SKILL --> TARGET
    TARGET --> RESULT

The Skill Runtime provides the controlled environment in which Skills are invoked.

Vendor APIs, SDKs, playbooks, scripts and command-line tools may exist inside a Skill, but they remain implementation details.

The public operational model is capability-based rather than vendor-based.

Nivron IQ¶

Nivron IQ provides intelligence and governance about the Nivron platform itself.

Its scope includes:

installation health;
release awareness;
upgrade recommendations;
lifecycle visibility;
known Nivron issues;
compatibility information;
platform advisories;
roadmap and support visibility.

Nivron IQ does not act as a generic third-party infrastructure vulnerability or operations intelligence platform.

Its primary purpose is to help customers understand the state and evolution of their Nivron installations.

flowchart LR
    MANAGER["Nivron Manager"]
    TELEMETRY["Selected Platform Telemetry"]
    IQ["Nivron IQ"]
    INSIGHT["Lifecycle, Health and Advisory Information"]

    MANAGER -.-> TELEMETRY
    TELEMETRY -.-> IQ
    IQ -.-> INSIGHT
    INSIGHT -.-> MANAGER

The authoritative Mission record remains within Nivron Manager.

Nivron SaaS¶

Nivron SaaS provides optional global and cloud-delivered capabilities.

Its responsibilities may include:

multi-installation governance;
consolidated reporting;
global audit visibility;
account and subscription coordination;
fleet-level platform status;
global administrative services;
cloud-assisted platform capabilities.

Nivron SaaS is not required to participate in every local operation.

It complements Nivron Manager without replacing the Manager's local operational authority.

flowchart TD
    subgraph CUSTOMER["Customer Environment"]
        MANAGER["Nivron Manager"]
        INFRA["Customer Infrastructure"]
    end

    subgraph CLOUD["Nivron Cloud"]
        SAAS["Nivron SaaS"]
        IQ["Nivron IQ"]
    end

    MANAGER --> INFRA
    MANAGER -. Optional synchronization .-> SAAS
    MANAGER -. Optional telemetry .-> IQ

This boundary preserves local autonomy while enabling global governance.

Local-First Architecture¶

Local-first is a core architectural principle of Nivron.

The essential operational path must remain available within the customer environment.

Operational Intent
        ↓
Nivron Manager
        ↓
Operational Brain
        ↓
Mission Lifecycle
        ↓
Scheduler
        ↓
Mission Execution
        ↓
Skill Runtime
        ↓
Skills
        ↓
Customer Infrastructure

The following responsibilities must not require permanent cloud connectivity:

operational governance;
authorization;
approval;
planning;
scheduling;
execution;
audit;
evidence retention;
local administration;
local observability.

Connectivity with Nivron SaaS and Nivron IQ must be explicit, controlled and designed around clearly defined synchronization boundaries.

Authority Boundaries¶

The architecture distinguishes local operational authority from global platform governance.

Domain	Primary Authority
Local operational decisions	Nivron Manager
Mission lifecycle and state	Nivron Manager
Infrastructure execution	Nivron Manager
Local evidence and audit	Nivron Manager
Local inventory and operational context	Nivron Manager
Multi-installation governance	Nivron SaaS
Global account and subscription coordination	Nivron SaaS
Nivron lifecycle and release intelligence	Nivron IQ
Nivron health and advisory intelligence	Nivron IQ

These boundaries reduce ambiguity and prevent the cloud layer from becoming an implicit dependency for local operations.

Shared Technical Foundations¶

The products use shared technical foundations where reuse is appropriate.

These foundations may include:

configuration;
identifiers;
database access;
API conventions;
security primitives;
audit primitives;
observability;
error handling;
background job abstractions;
common domain utilities.

flowchart TD
    MANAGER["Nivron Manager"]
    SAAS["Nivron SaaS"]
    IQ["Nivron IQ"]
    FRAMEWORK["Shared Platform Foundations"]

    MANAGER --> FRAMEWORK
    SAAS --> FRAMEWORK
    IQ --> FRAMEWORK

Shared foundations must not create hidden runtime dependencies between products.

Code reuse and product coupling are different architectural concerns.

A shared framework may support multiple products without requiring those products to execute as a single distributed system.

Data Ownership¶

Each product must own the data required to fulfill its responsibilities.

Nivron Manager owns¶

local identities and operational roles;
local inventory;
Missions;
plans;
schedules;
execution records;
local evidence;
local audit records;
local configuration;
local operational state.

Nivron SaaS may own¶

global accounts;
subscriptions;
installation registry;
global governance configuration;
consolidated reports;
synchronized global audit views;
cloud-delivered service data.

Nivron IQ may own¶

release metadata;
lifecycle metadata;
compatibility data;
Nivron advisories;
installation health summaries;
platform intelligence models.

Synchronization must not obscure the source of authority for each record.

Security Architecture¶

Security is applied across every architectural layer.

The platform must provide:

authenticated identities;
explicit authorization;
organization and tenant isolation;
service identity;
secret protection;
policy enforcement;
approval controls;
execution isolation;
audit integrity;
evidence integrity;
secure communication boundaries.

Critical governance decisions must remain deterministic and auditable.

AI-assisted capabilities may support interpretation, classification and recommendation, but they must not replace explicit authorization, policy or safety controls.

Evidence and Audit¶

Evidence is a first-class architectural concern.

Every governed execution must remain traceable to:

the initiating identity;
the organization;
the Mission;
the plan;
the approval decision;
the execution target;
the selected Skill;
the technical result;
the verification outcome.

flowchart LR
    IDENTITY["Identity"]
    MISSION["Mission"]
    PLAN["Plan"]
    EXECUTION["Execution"]
    RESULT["Result"]
    VERIFY["Verification"]
    AUDIT["Audit and Evidence"]

    IDENTITY --> MISSION
    MISSION --> PLAN
    PLAN --> EXECUTION
    EXECUTION --> RESULT
    RESULT --> VERIFY
    VERIFY --> AUDIT

Audit must describe what happened.

Evidence must support why the platform considers the operation successful, failed, rejected or incomplete.

Deployment Models¶

The platform supports different deployment models without changing its core operational concepts.

Autonomous Local Deployment¶

Nivron Manager operates independently inside the customer environment.

Connected Deployment¶

Nivron Manager operates locally and synchronizes selected information with Nivron SaaS and Nivron IQ.

Global SaaS Services¶

Nivron SaaS and Nivron IQ provide centralized capabilities without becoming the execution authority for the customer environment.

flowchart LR
    LOCAL["Autonomous Local"]
    CONNECTED["Connected Local"]
    GLOBAL["Global SaaS Services"]

    LOCAL --> CONNECTED
    CONNECTED --> GLOBAL

The connected model extends the platform.

It does not redefine the local authority model.

Architectural Principles¶

The Nivron architecture follows these principles:

Local operational authority¶

The customer environment remains operationally autonomous through Nivron Manager.

Governance before execution¶

No technical operation should bypass context, authorization, policy and approval controls.

Mission-driven operations¶

Every governed operation is represented by a Mission with an explicit lifecycle.

Separation of decision and execution¶

The Operational Brain governs and coordinates. Skills implement technology-specific actions.

Evidence by design¶

Execution must produce structured and attributable evidence.

Explicit authority boundaries¶

Local, global and intelligence responsibilities must remain clearly separated.

Vendor independence¶

The platform model must not be defined by a specific infrastructure vendor or automation technology.

Shared foundations without product coupling¶

Reusable engineering capabilities must not create unnecessary runtime dependencies.

Stable concepts, evolving implementations¶

Mission, governance, evidence, policy and authority boundaries should remain stable even when implementation technologies evolve.

Deterministic control¶

Authorization, isolation, approval, safety and policy enforcement must remain explicit and verifiable.

Documentation Map¶

The Architecture section is organized to progressively deepen the platform model.

Architecture
│
├── Architecture Overview
│
├── Product Architecture
│   ├── Nivron Manager
│   ├── Nivron IQ
│   └── Nivron SaaS
│
├── Operational Architecture
│   ├── Operational Brain
│   ├── Mission Lifecycle
│   ├── Scheduler
│   ├── Mission Execution
│   ├── Skill Runtime
│   ├── Skills
│   └── Evidence and Audit
│
├── Technical Foundations
│   ├── Platform Framework
│   ├── Identity
│   ├── Database
│   ├── APIs
│   ├── Observability
│   └── Security
│
├── Deployment Architecture
│   ├── Local Deployment
│   ├── Connected Deployment
│   ├── SaaS Deployment
│   └── Network Architecture
│
└── Repository Structure

Not every page is implemented yet.

This map defines the target organization of the architecture documentation.