Presets Reference

The extension ships with four built-in presets. Each is a self-contained YAML configuration defining roles, allowed relations, and matrix definitions.

requirements-engineering

Systems and software engineering. Three roles with comprehensive relation coverage.

Roles

requirement, design, test

Matrices

requirements-to-design, requirements-to-tests

Version

1.0.0

Relations:

Relation Forward Reverse

requirement → requirement

refines

refined_by

requirement → requirement

depends_on

is_prerequisite_of

requirement → requirement

conflicts_with

conflicts_with

design → requirement

addresses

addressed_by

design → design

depends_on

is_prerequisite_of

design → design

refines

refined_by

design → test

validated_by

validates

test → requirement

verifies

verified_by

Each pair is declared once; the reverse direction is allowed automatically.

Matrices:

Name Rows Columns

requirements-to-design

requirement

design

requirements-to-tests

requirement

test

agile

Agile/Scrum teams. Eight roles mapping the Scrum backlog.

Roles

epic, feature, user_story, acceptance_criterion, task, spike, bug, test

Matrices

epic-progress, story-completion, sprint-backlog, test-coverage

Version

1.0.0

Relations:

Relation Forward Reverse

epic → feature

contains

contained_in

epic → user_story

contains

contained_in

epic → test

validated_by

validates

feature → user_story

broken_down_into

broken_down_from

feature → test

verified_by

verifies

user_story → epic

part_of

contains

user_story → feature

part_of

contains

user_story → acceptance_criterion

has

belongs_to

user_story → task

broken_down_into

broken_down_from

user_story → spike

requires

required_by

user_story → test

verified_by

verifies

user_story → bug

affected_by

affects

acceptance_criterion → user_story

belongs_to

has

acceptance_criterion → test

validated_by

validates

task → user_story

implements

implemented_by

task → spike

implements

implemented_by

task → test

affects

affected_by

task → bug

fixes

fixed_by

spike → user_story

investigates

investigated_by

spike → task

results_in

result_of

bug → user_story

blocks

blocked_by

bug → task

fixed_by

fixes

bug → test

reproduced_by

reproduces

test → user_story

verifies

verified_by

test → acceptance_criterion

validates

validated_by

test → task

tests

tested_by

test → spike

tests

tested_by

test → bug

reproduces

reproduced_by

medical-iec62304

Medical device software compliant with IEC 62304. Safety classification support.

Roles

system_requirement, software_requirement, software_item, software_unit, risk, hazard, mitigation, regulation, standard, test_procedure, test_case, test_report, soi

Matrices

risk-mitigation, requirements-allocation, software-verification, test-traceability, soi-traceability

Version

1.0.0

Relations:

Relation Forward Reverse

system_requirement → software_requirement

allocated_to

allocated_from

system_requirement → risk

mitigated_by

mitigates

system_requirement → regulation

derived_from

derived_into

system_requirement → standard

complies_with

complied_with_by

software_requirement → software_requirement

refines

refined_by

software_requirement → software_requirement

depends_on

is_prerequisite_of

software_requirement → software_item

implemented_by

implements

software_requirement → software_unit

implemented_by

implements

software_requirement → risk

addresses

addressed_by

software_requirement → test_procedure

verified_by

verifies

software_requirement → soi

uses

used_by

software_item → software_requirement

satisfies

satisfied_by

software_item → software_unit

composed_of

composed_of_by

software_item → risk

addresses

addressed_by

software_item → test_procedure

validated_by

validates

software_unit → software_requirement

implements

implemented_by

software_unit → software_item

part_of

contains

software_unit → test_procedure

tested_by

tests

risk → hazard

caused_by

causes

risk → mitigation

mitigated_by

mitigates

risk → software_requirement

requires

required_by

risk → system_requirement

requires

required_by

risk → test_procedure

verified_by

verifies

hazard → risk

poses

posed_by

hazard → mitigation

mitigated_by

mitigates

mitigation → risk

mitigates

mitigated_by

mitigation → hazard

addresses

addressed_by

mitigation → software_requirement

implements

implemented_by

regulation → system_requirement

requires

required_by

regulation → software_requirement

requires

required_by

standard → system_requirement

informs

informed_by

standard → software_requirement

informs

informed_by

test_procedure → software_requirement

verifies

verified_by

test_procedure → software_item

validates

validated_by

test_procedure → software_unit

tests

tested_by

test_procedure → risk

validates

validated_by

test_procedure → mitigation

validates

validated_by

test_procedure → test_case

contains

contained_in

test_procedure → test_report

generates

generated_by

test_case → test_procedure

part_of

contains

test_case → software_requirement

traces_to

traced_by

test_report → test_procedure

documents

documented_by

test_report → test_case

documents

documented_by

soi → software_requirement

fulfills

fulfilled_by

soi → regulation

complies_with

complied_with_by

minimal

Two roles — the simplest possible setup.

Roles

requirement, test

Matrices

requirements-tests

Version

1.0.0

Relations:

Relation Forward Reverse

requirement → requirement

depends_on

is_prerequisite_of

requirement → test

verified_by

verifies

test → requirement

covers

covered_by

Preset metadata schema

Each preset YAML file follows this structure:

Key Type Description

name

string

Unique preset identifier

description

string

Human-readable explanation of domain and intended use

version

semver

Independent version, separate from the extension

extends

string

Name of a parent preset to inherit from. The parent’s roles, relations, matrices, and labels are deep-merged under this preset (child wins on conflict).

author

string

Preset author or organization

tags

string[]

Keywords for categorisation

compatibility

object

minExtensionVersion: minimum extension version (reserved for future checks)

traceability.roles

string[]

Ordered list of valid role names

traceability.relations

map

sourceRole → targetRole → type → { reverse }. Each relation type has a mandatory reverse (the authorable name from the other side).

traceability.labels

map

Display-only type → human-readable name. Optional; defaults to the humanized type name.

traceability.matrices

object[]

Array of matrix definitions (name, rows, columns, coverageRelations)

neo4j.queries

object[]

Optional named Cypher queries shipped with the preset

documentation

object

description (markdown), examples (string[])

Initialize from a preset

To customize a preset, initialize a local copy:

npx antora-tracer preset init -n requirements-engineering -o ./config/

This writes the full YAML to ./config/traceability.yml. Edit it, then point your playbook at the file:

antora:
  extensions:
    - require: antora-tracer/antora-extension
      config:
        configPath: ./config/traceability.yml

List available presets

npx antora-tracer preset list
# → requirements-engineering, agile, medical-iec62304, minimal

Show a preset’s details:

npx antora-tracer preset show requirements-engineering

Related