Systems

A System is the Istari Digital Platform's primitive for grouping related Resources so they can be versioned, shared, and composed together. A System can include other Systems as Subsystems to mirror real-world decomposition.

Note: A Resource is any registered file in the platform — uploaded or connected, model or artifact. See Resources for how a file becomes a Resource. Resources keep their identity and revision history regardless of which Systems reference them.

Why group Resources into a System?

Resources do useful work on their own. But most engineering deliverables are made of many Resources, and those Resources are tied together by facts that are not visible on any single one of them:

• Same audience. A wing model, its FEA results, the manufacturer's drawings, and the test report are all relevant to the same group of people. Sharing them as a unit, with consistent permissions, beats hand-managing access on each Resource.
• Same logic. Parts of one product belong together. The avionics module, its harness, its firmware, and its bench-test results describe one assembly. Treating them as a group preserves the engineering relationships that connect them.
• Same lifecycle. Resources move through review, validation, simulation, certification, and release together. When a System freezes for PDR, every Resource in it freezes; when it ships, every Resource ships at the same revision.

A System makes those facts explicit. Ownership, sharing, and version tracking apply to the group, not to each Resource individually.

A System is more than a folder

It's tempting to picture a System as a folder of files — and at first glance it works that way. You give it a name, drop Resources into it, and share the whole thing. The platform supports that mental model directly.

A System captures a few things a folder can't:

• A Resource can belong to many Systems at once. A common hydraulic actuator model can sit in landing gear, hydraulics, and flight controls simultaneously. Each System sees the same Resource identity and the same revision history — there's no copy.
• Systems compose into other Systems. A Subsystem is itself a System, with its own owner, lifecycle, and access — but referenced into a parent. Aircraft can include Propulsion, which can include Engine, recursively.
• Versioning is built in. When a Resource updates, the Systems tracking it see the new revision. When you mark a state worth keeping — a review, a delivery, an audit point — the platform records exactly what was in the System at that moment.

The result is closer to a graph of relationships between coherent groups of Resources than a directory tree: the same Resource can appear in several engineering contexts, Systems compose into one another, and revision state is meaningful and inspectable along every edge of the graph.

Systems and Subsystems

A System answers a simple question: what is this thing? It's the named container for a coherent set of Resources — a vehicle, an assembly, an analysis package, a deliverable — with a name, an owner, and zero or more Subsystems. References to Resources can be:

• Tracked — the System follows the Resource's latest revision automatically.
• Pinned — the System is locked to a specific revision until you change it explicitly.

You can mark significant moments in a System's life — design reviews, deliveries, certification milestones — with a tag. The first such tag is the baseline; other Systems referencing this one default to it.

A Subsystem answers a different question: what is it made of? It's another System linked into a parent. The parent references the child by tag, so the parent's recorded state deterministically resolves which version of the child it captured.

Subsystems compose. An aircraft System can include Propulsion as a Subsystem, which can itself include Engine as a Subsystem. Each level is a stand-alone System with its own owner, Resources, and lifecycle — composed into the parent only when needed.

Map a System to your way of working

The platform deliberately does not prescribe a methodology. The same primitives map cleanly to several patterns; pick what matches your program and adapt as you go.

Mirror your product breakdown

The natural starting point is to mirror your product's decomposition. One top-level System per product, with Subsystems for each major assembly. The hierarchy is durable — once established it should rarely change.

For an aircraft program that might look like:

• Aircraft (top-level System)
  • Airframe (Subsystem) — fuselage, wings, empennage
  • Propulsion (Subsystem) — engine, fuel system, thrust reverser
  • Avionics (Subsystem) — nav, comms, flight management
  • Flight Controls, Electrical, Hydraulics, Landing Gear, ECS, Payload — each its own Subsystem.

Each Subsystem can decompose further or stay flat. Depth is your call; the platform does not impose a level.

Map the RFLP layers into one System

For programs running an MBSE methodology like RFLP — Requirements, Functional, Logical, Physical — the natural fit is to keep all four views as Resources inside the same System rather than scattered across separate tools:

RFLP layer	How it lives in a System
Requirements	A Resource — an .xlsx requirements sheet, a ReqIF export, a Cameo requirements package. Versioned, shared, and reviewed alongside everything else.
Functional	A Resource — Cameo, Simulink, IDEF model. The function tree lives inside the model file; the System versions the file.
Logical	The Subsystem tree itself, plus interface-definition Resources. Decomposing your product into Subsystems is the logical view.
Physical	CAD, FEA, software, and test-data Resources tied to the Subsystem they describe. The native strength of the digital thread.

Because requirements, functional models, logical decomposition, and physical artifacts all live in one Istari Digital System, traceability across them becomes a first-class platform concern — visible, versioned, and shareable as a single unit.

Pick a granularity that matches your reuse

• Subsystem when the child is part of the parent and follows its lifecycle. The child still has its own owner and its own life — but in the parent it's referenced, not duplicated.
• Separate System when the child has independent significance: shared across many parents (a common component library), used by many programs, or running a distinct lifecycle (a long-lived variant program in production while the main program continues to evolve).

A Resource referenced from multiple Systems is normal. A Subsystem referenced from multiple parent Systems is normal. The platform treats both as relationships, not copies.

Key details

• Data sovereignty. File contents stay in your data plane (e.g. S3, Azure) or in their connected third-party source. The platform's control plane holds only metadata — Resource identity, revisions, System membership, sharing.
• Permission inheritance. Granting a role on a System cascades to the Resources it tracks — see System permission inheritance below.
• Baseline. Every System starts with a baseline reference state. Other Systems that reference this one default to it.
• One Resource, many Systems. A registered Resource is one identity. If the same Resource is tracked by multiple Systems, a user with access to any of those Systems can reach it.

System permission inheritance

When you share a System with a user, their role on the System automatically cascades to the Resources tracked by the System. You don't need to share each one individually.

System role	Tracked Resources	Archive permission
Viewer	Can view	No
Editor	Can view and edit	No
Administrator	Can view and edit	No
Owner	Can view and edit	No

• Archive does not cascade. Only users with direct Owner or Administrator access on a Resource can archive it.
• Cascade applies to all tracked Resources. Including artifacts tracked without their parent model.
• Multiple Systems, broader access. If a Resource is tracked by more than one System, a user with access to any one of those Systems can reach it.
• Removing a System role removes the cascaded access along with it. Direct access granted on individual Resources is preserved.
• Subsystem contents do not inherit. Permissions stop at the parent. To view a Subsystem's Resources, a user must be granted access to the Subsystem itself.

For the bigger picture on sharing and roles, see Sharing, security, and access control.

How to work with Systems

User guide (UI):

• Systems guide — Create a System, add Resources, manage versions, mark significant states, and share.

Python client (SDK):

• SDK setup — Install and configure the istari-digital-client package.
• Systems & snapshots — create_system, plus the System composition section for nesting Subsystems.

Related terms

Artifact, Baseline, Model, System