Introduction to Data Types in Flow

Last updated: December 30, 2025

In Flow, there are seven different data types that may exist in your Project: 

  • Requirements 

  • Systems 

  • Design Values 

  • Model Values 

  • Test Cases 

  • Test Plans

  • Documents

Flow allows you to easily make relationships between all these data types with clear traceability. Our complete change history always tracks every change, so that your team clearly knows who changed what, when, and why.

Requirements

In Flow, the atomic unit of work is a Requirement. Each Requirement contains a unique identifier (REQ-ID), a Requirement Name, and a Requirement Statement.

REQ-ID

A system-generated unique identifier assigned sequentially (e.g., REQ-1, REQ-2, ...).

Requirement Name

A concise, human-readable title describing the requirement.

Requirement Statement

A detailed explanation of the requirement.

You may use rich text formatting, keyboard shortcuts (e.g., Cmd/Ctrl + B), and Markdown syntax. Images can also be added via drag-and-drop.

Requirement Value

A quantitative attribute extracted from the requirement statement—for example, “10 Hz” or “> 5000 Lbs”.

Parameterized requirement values enable automatic verification checks by comparing requirement targets against actual values.

Flow’s AI assistant automatically detects and converts numerical expressions into Requirement Values when possible.

Units

Requirement objects in Flow automatic track units and can verify comparisons to identify mismatching units.

Parent Requirement

A higher-level parent Requirement that this Requirement rolls up to, establishing hierarchical structure.

Cross-Link

A lateral relationship between two Requirements at the same hierarchical level. This is useful for capturing dependencies or interactions across branches.

Requirement Type

A customizable tag used to categorize Requirements. Examples include Functional, Safety, or Regulatory. Types can be configured in project settings.

Check

A mechanism used by Flow for validating engineering intent, Checks determine whether the Requirement is currently satisfied. There are five types of Checks:

  • Manual — A simple toggle indicating Pass, Fail, or Inconclusive.

  • Target — Compares the Requirement Value against an actual numerical Design Value.

  • Summary — Automatically passes only if all descendant Requirements pass their own Checks.

  • Document — Passes when all linked documents are marked as passed.

  • Test Case — Passes when all linked test cases have passed.

Custom Fields

Any additional custom fields that have been defined in settings.

Eg: Rationale, Priority Level etc.

Systems

Systems can be thought of as containers that help organize your project. A system can contain the requirements that define it, the tests that verify it, the documents that are linked to them, and more.

Systems, sometimes referred to in Flow as “Design Units”, are useful for representing a product breakdown structure, with each component containing all of its requirements through to verification and validation. In Flow objects can be in more than one system to natively support cross-functional collaboration.

Systems may have a single parent system and/or multiple children systems. Systems may also have interfaces that exist between each other. Interfaces may have requirements that define them, as well as tests that verify them.

System Properties

  • System Name

  • Parent System

  • System Requirements

  • Interfaces

    • Interface ID

    • Interface Type

    • Source System

    • Target System

    • Requirements

  • Custom Fields

Design values

A Design Value in Flow is a variable that stores quantitative information. It can define a requirement value, drive actual values for verification checks, and be referenced in documents. Design Values retain a full history of changes, enabling traceability and What-If Analysis to understand downstream dependency impacts. When a Design Value is updated, the change propagates automatically across all its uses in Flow.

Design Value Properties

  • Unique identifier assigned sequentially (e.g., VAL-1, VAL-2, ...).

  • Name

  • Description

  • Value - this can be one of the following types

    • number

    • range

    • aggregation

      • sum, product, mean, min, max, division, or system

    • text

    • boolean

  • Unit

  • Custom Fields

Model Values

A Model Value stores outputs from connected models in the Analysis tab, such as simulation results, optimization outputs, or derived engineering parameters. 

This allows model results to be captured as first-class data in Flow, enabling traceability, reuse, and direct comparison against requirements and other values. Model Values update automatically whenever the underlying model is re-run, ensuring downstream analyses and checks always reflect the latest results.

Model Value Properties

  • ID - Automatically assigned (e.g., MOD-1)

  • Name

  • Value

  • Units

Test Cases

A Test Case defines a procedure used to verify Requirements or Systems. It includes metadata, linked objects, step-by-step instructions, and a record of all historical executions.

Test Case Properties

  • Unique identifier assigned sequentially (e.g., TCS-1, TCS-2, ...).

  • Name

  • Description

  • Test Case Type

  • Custom Fields

Steps

A Test Case contains an ordered list of Steps. Each Step includes:

  • Action — The instruction to perform.

  • Expected Result — The outcome required for the Step to pass.

Steps can be added, removed, or reordered at any time.

Runs

Each time a Test Case is executed, Flow creates a Run. Running a test opens an interactive UI where each Step may be marked:

  • Pass

  • Fail

  • Skip

  • Pending

A Run records:

  • Per-step results

  • Overall passing percentage

  • Final status

  • Notes and commentary

  • Attached files or URLs

  • Custom fields

All Runs are listed in the Test Case’s Runs section for full traceability.

Test Plans

A Test Plan is a group of Test Cases designed to be executed together. Test Plans are built to help teams manage test campaigns, system acceptance tests, and automated software testing.

Test Plan Properties

  • Unique identifier assigned sequentially (e.g., TEST-1, TEST-2, ...).

  • Name

  • Description

  • Evidence attachment/URL

  • Custom Fields

Sequential Test Cases

The list of Test Cases included in the Test plan.

Test Cycles

Each time a Test Plan is executed, Flow creates a Test Cycle. A Test Cycle contains:

  • All individual Test Runs from each Test Case

  • Overall pass/fail metrics

  • Time-stamped execution history

  • Notes and attachments

  • Custom fields

Test Cycles allow teams to audit multi-test verification efforts with complete transparency.

Documents

A Document in Flow represents any external or internal artifact stored or referenced by the project such as PDFs, images, spreadsheets, analysis reports, etc.

Document Properties

  • ID - Automatically assigned (e.g., DOC-1).

  • Name

  • Description

  • File type

  • Version history

  • Review workflow

  • Linked Requirements, Systems, and Test Cases

  • Custom fields

Documents can be used in Document Checks, verifying Requirements when all linked documents are approved.

Sections

Documents in Flow contain rearrangeable sections. The document viewer will automatically create a Table of Contents in the left side bar. Each section contains a title and a description box to insert rich text, images, tables, code blocks, equations, or links to requirements, design values, people, and more.

Note: Every object in Flow automatically tracks and displays: Version, Owner, Reviewers, Review Status, Configurations, Last Updated, Created On, and Created By.