Understanding the ArQiver hierarchy

Purpose

Before configuring ArQiver, it helps to understand the order in which the main concepts relate to each other.

This page explains the hierarchy in practical terms. It is meant to help users understand what comes first, what belongs where, and why roles and products are always tied to context.

Just as importantly, this page explains that ArQiver works with two connected layers:

• a design layer, where structure, meaning, and rules are defined;
• a runtime layer, where real operational data is handled.

The hierarchy at a glance

ArQiver is structured in layers:

1. Enterprise Data Space
2. Domains
3. Design layer
4. Runtime layer
5. Roles and people working across those layers

Each layer depends on the one above it. You do not start with runtime work or workspace actions. You first create the structure that gives those actions meaning.

1. Enterprise Data Space

The Enterprise Data Space is the top-level environment for the organisation.

This is the outer boundary of the archive. It represents the organisation as a whole and provides the overall governance context. At this level, you are not yet dealing with operational work. You are establishing the space in which that work will later happen.

Typical enterprise-level roles include:

• Dataspace Admin
• Dataspace Owner

These roles operate above individual domains.

2. Domains

Inside the enterprise data space, the organisation is divided into domains.

A domain is a meaningful organisational context. It can represent a department, service area, business unit, or another bounded part of the organisation. Domains are important because ArQiver keeps responsibilities and meaning tied to context.

This means that domains are not just folders or labels. They help define:

• who is responsible;
• which roles apply;
• how products are grouped;
• and which context users are working in.

Within a domain, ArQiver then separates two different kinds of work: designing the structure of the archive, and working with the real data that flows through it.

3. Design layer

The design layer is the abstract side of ArQiver.

This is where you define what may exist before real operational work begins. In practical terms, this includes things such as:

• data cards;
• metadata cards;
• retention protocols;
• records management;
• templates;
• product and stream setup.

You can think of this as the side where the archive is designed, governed, and reviewed. It describes the structure that future runtime work must follow.

4. Runtime layer

The runtime layer is the side where real work happens.

This is where active products, active streams, workspace actions, collections, and real archived objects come into play. In object-oriented terms, you could say the design layer defines the class, while the runtime layer is where instances are created and real data starts to exist.

This is why ArQiver does not begin with runtime activity alone. First the design layer defines meaning, rules, and context. Only then can runtime work happen in a controlled and understandable way.

Products and streams inside those layers

Within a domain, ArQiver organises work around products.

A product represents a real service, offering, or operational unit that the organisation delivers. Products are not just labels for grouping. They are the point where meaning, accountability, and execution come together.

Products belong to a domain. They do not float above the hierarchy on their own.

Within a product, ArQiver uses streams.

Streams represent the concrete flow of work or information inside that product context. A stream is always subordinate to a product. It does not define meaning by itself. The product and domain above it provide that context.

This is one of the reasons ArQiver does not start with “just uploading data.” It first defines where the work belongs and under which meaning and responsibility it operates.

Products and streams therefore exist across the boundary between design and runtime:

• on the design side, they are defined and configured;
• on the runtime side, they become active and carry real work and data.

5. Roles and people work across both layers

Roles are not simply another level in the hierarchy. They are the responsibilities through which people work within the hierarchy.

Some roles mainly shape and govern the design layer. Others mainly work in the runtime layer. Some roles connect the two.

Examples:

• enterprise and governance roles help shape structure and responsibility;
• product and review roles help define and approve the abstract setup;
• operators mainly work with live products, streams, and data in runtime;
• users may hold multiple roles, but they should act from one active role at a time.

This matters because ArQiver is highly context-sensitive. A user can have different responsibilities in different domains, and the system is designed to keep those responsibilities clear and properly separated.

If you need more detail, see Roles and responsibilities.

Operational work in the workspace

Only after the structure above is in place does operational work become meaningful.

At that point, operators can work in the workspace, collections can be managed, and product-related execution can happen in the right context.

Without the hierarchy above, workspace activity would lose meaning and governance.

Why the order matters

ArQiver is designed so that:

• enterprise gives the overall boundary;
• domains give contextual separation;
• the design layer defines meaning, structure, and rules;
• the runtime layer handles live work and real data;
• roles carry responsibility across those layers;
• and workspace actions happen only after that structure exists.

This order helps organisations work with more clarity and consistency. In practice, it helps avoid problems such as:

• assigning the wrong responsibility to the wrong person;
• mixing work across domains;
• making changes from the wrong role;
• and losing track of why a piece of information exists in the first place.

In one sentence

ArQiver starts with structure and context, then defines meaning and rules in the design layer, and only then allows real execution and data in the runtime layer.