Skip to main content

Curation and Conformance Checks

The pipeline checks at several points whether the manifest, the Artemis source, and the generated model fit together. This page explains each check, so that you know why a run stopped and what it expects from you. For a lookup table of all codes, see Diagnostic Codes.

Blocking findings and warnings​

Every check reports findings with a stable code. A blocking finding stops the run: there is no snapshot, and the delivery workflows publish nothing. A warning or an info finding appears in the report, but the run still passes.

Curation gaps and conformance mismatches stop the model stage at once, because no trustworthy model can be built. The run then never reaches the workflow checks, so fix these findings first and run the pipeline again. All other blocking findings let the run continue, so that the report shows every finding; the package stage then refuses to write a snapshot.

Curation: does the manifest decide everything?​

Before it assembles a model, the model stage compares the manifest with the scan. It collects every gap in one pass, so the report lists all of them at once.

The check is tiered. A module that Artemis itself presents as a feature, because the server enumerates it or the admin page shows it, needs a decision: a features entry or a notModeled entry. Every other candidate without an entry, such as a runtime toggle, a Spring profile, or a module that only has a condition class, stays out of the model and appears as UNMODELED_ANCHOR with severity info.

These findings block the run:

  • UNDECLARED_CANDIDATE: a module that Artemis presents as a feature has no features or notModeled entry. This is the usual sign that Artemis added a module.
  • RELATION_CANDIDATE_UNDECLARED: the scan found a dependency between two modeled features, and the manifest has neither a constraint nor an ignored relation for it.
  • MANIFEST_ORPHAN_ANCHOR: a manifest entry names an anchor that matches no candidate, or more than one. Artemis usually renamed or removed something.
  • MANIFEST_CURATION_CONFLICT: two entries collide, for example two entries for one candidate or two features with the same id.
  • EXTRACTOR_ERROR: a scanner could not read its source. The facts of the run are incomplete, so the run stops.

Two warnings point to missing explanations: EXCLUSION_REASON_UNSPECIFIED for a notModeled entry without a reason, and EXCLUDED_TOGGLE_RATIONALE_MISSING for a runtime toggle in notModeled without a rationale. A third warning, MANIFEST_CONSTRAINT_REDUNDANT, reports a declared constraint that repeats a derived exclusion of an alternative group; the pipeline drops the declared copy.

Configuration derivation​

The pipeline finds the configuration keys of a feature in the Artemis source. A feature is guarded by its condition class, for example AthenaEnabled, and a technical profile feature by its @Profile constant. A key belongs to the feature when it is read only in files with that guard: through @Value, below a @ConfigurationProperties prefix of such a file, or below the namespace of the feature's enabled key. A key that other code also reads, such as the server URL, belongs to no feature.

The pipeline then classifies each key. A key whose default is a placeholder, or whose name ends in an endpoint or a credential, is a deployment input and becomes a configuration mapping. Every other key is a tunable with a working default: the report lists it as CONFIG_MAPPING_TUNABLE_SKIPPED, and the model leaves it out. A key whose name or placeholder suggests a credential is a secret.

The configuration entries of the manifest take precedence: they add keys the source does not reveal, and reject derived keys with action: exclude (CONFIG_MAPPING_REJECTED). Every derived deployment input appears as CONFIG_MAPPING_DERIVED. All three codes have severity info. The full result per feature is in model/config-derivation.json and in the Configuration derivation section of the report.

The derived mappings of technical features also include their Compose file or Spring profiles. When the pipeline cannot derive them, the run fails with TECHNICAL_MAPPING_UNDERIVABLE.

Conformance: does the model match the manifest?​

After assembly, the pipeline compares the generated model with what the manifest declares: membership, names and descriptions, kind, category, defaults, tree position, group types, capabilities, configuration mappings, constraints, and order. Any difference is a GENERATED_MODEL_CONFORMANCE_MISMATCH. It does not mean that a decision is missing: the assembly code no longer produces what the manifest declares, so involve a developer.

A constraint whose source or target is not part of the model is a DANGLING_GENERATED_CONSTRAINT. It usually means that a constraint names a feature you just excluded.

Model and catalog checks​

The model stage then validates the generated model with the same integrity rules that the application uses at startup (GENERATED_MODEL_INVALID). It adds one delivery rule: TECHNICAL_FEATURE_ROLE_LEAK, a technical feature that would be visible or configurable for teachers.

The stage also builds the config-key catalog from the configuration mappings of the model. When a mapped key has no default in the Artemis application*.yml files, the run fails with CONFIG_KEY_CATALOG_DRIFT: the pipeline cannot prove that Artemis knows the key.

All of these findings block the run.

Guided workflow checks​

The workflow stage checks the authored guided workflow against the generated model. A broken reference, such as an option that selects a feature the model does not have, blocks the run as GENERATED_WORKFLOW_INVALID.

The other workflow findings appear in guided-workflow-validation.json with codes that start with GUIDED_WORKFLOW_. Errors among them block the run, for example a published option with TODO text or a template that selects and deselects the same feature. Warnings do not, for example a feature that no published option covers yet. The report summarizes them as GUIDED_WORKFLOW_FINDINGS. Update the Guided Workflow explains how to resolve them.

Source observations​

The scan also reports what looks inconsistent inside Artemis itself. CLIENT_SERVER_MIRROR_MISMATCH means that the Artemis client and server disagree about a module or a toggle, and MODULE_CONSTANT_ASYMMETRY means that a module has a configuration key but no module constant, or the other way round. These findings describe Artemis, not your manifest, and they do not stop the run.

Where findings show up​

Every finding of a run appears in report/index.html and report/extraction-report.json. The curation decisions and gaps are also in model/manifest-conformance-report.json, and the workflow findings in workflow/guided-workflow-validation.json. Read the Report walks through them.

Search documentation