Glossary

This page defines the preferred terms for STIG concepts in conversation, progress updates, reviews, Markdown documentation and specifications, KDoc, and code comments, including analysis_review.md and Gradle task reports. Use one preferred term for each concept. Prefer the same concepts in new code identifiers while preserving exact existing API names, task names, schema fields, paths, and quoted evidence. Terms are sorted alphabetically, ignoring case. Acronyms and examples appear under the definitions when needed.

Call LLVM .bc files bitcode, their readable .ll representation LLVM text, and build.gradle.kts a Gradle build script. When describing a problem, name the file, what it is used for, the exact function or field, and what is wrong. Distinguish a function definition, declaration, call, or reference in LLVM from a generated report about that function. Identify an affected sink only when the evidence establishes that relationship.

Edit the native Writerside XML in stig-docs/src/main/kotlin/com/stigway/cfg/glossary.xml to change a definition, acronym, or example. This page is generated from that authored source and preserves its alphabetical order. Definitions and labelled acronym/example paragraphs use plain text in XML; Markdown formatting is added for this page.

Writerside definition lists support the Markdown syntax used here. Writerside tooltips are a separate feature requiring inline tooltip elements. Inline tooltip markup remains deferred; ordinary Markdown links to this page can be used.

Read the definitions together with Check and align analysis evidence, Automated cascading and data-flow analysis, and Bitcode rewrite modeling. Those pages describe the workflows; this page explains their vocabulary. Paths beginning with llvm/, configuration/, or review/ in the examples are paths inside an evidence ZIP. Local task-output paths are relative to the activity's build/stig/ directory. The ZIP's evidence_manifest.json identifies the corresponding producing tasks and concrete captured paths; a producing task and its output directory can have different names.

ABI function variant: One of several exact compiler-generated functions implementing different cases of a C++ operation. Example: Complete-object and base-object constructors can have different exact symbols.
Action code: A machine-readable identifier for a required or proposed next action. Example: actionCodes in the transform review.
Action item: A described next step for resolving a reported issue. Example: actionItems in the transform review.
Activation: Selecting a shared rule for an activity through a use(...) entry. When describing a change, name the entry and the rule instead of using this word alone. Example: "Add the missing activity use(...) entry for app::Send."
Active activity transform rule: The resolved combination of one activity use(...) entry and its matching project registry rule definition. Selection alone does not prove that the rule is appropriate, reviewed, or successfully applied. Example: A rule defined in the project Gradle build script and selected in the activity Gradle build script is active for that activity.
Activity: One configured software element whose source code is analyzed. An activity has its own selected code, transform rules, analysis results, and review. Example: :activities:fusion_activity is a Gradle project path identifying one activity.
Activity Gradle build script: The activity's Gradle build script. Its analyzerInput \{ bitcodeTransforms += \{ ... \} \} block selects shared rules with use(...) entries and records their activity-specific reviews. Example: activities/fusion_activity/build.gradle.kts
Activity summary: The review's compact table of activity counts. Read each metric with its counting unit and detailed evidence, rather than adding all the rows into a total. Example: Active rules, final-body matches / checked rules, required missing definitions, Captured CRITICAL, and Captured HIGH.
Activity transform-rule use(...) entry: One selector authored in an activity's analyzerInput.bitcodeTransforms block. It selects a matching project registry rule for that activity. Say whether the entry is present or missing. Example: use(qualifiedFunctionName = "amp::detail::assertion_failed")
addFunctionImplementation: A transform rule that supplies function implementations by compiling its configured source file. It does not request a NOP or transfer replacement for those functions. A source file can define several functions, including several matches for one name-wide rule. Example: The configured time_utils.cpp can supply both overloads of IsTimePointIncreased.
Affected item: The exact function, global, rule, sink, or task to which a problem refers. The record identifies it with subjectId. Example: The exact LLVM symbol for CalibrationValidator::UpdateChannel(...).
AI_REVIEWED: Historical transform-confirmation enum value for agent review. Current shared rules use reviewStatus.
Alias target: The definition to which an alias resolves. Use the recorded mapping when comparing P5 input matches with P5 rewrite applications. Example: If C1 aliases C2, the target is the C2 definition.
Alignment: Established agreement of the relevant observations across stages under the justified analysis models. Matching counts or function names alone does not establish it.
Allowed external runtime symbol: A symbol intentionally left external under the tool's recorded runtime policy. It must have explicit evidence explaining that treatment. Example: Captured allowed_external_symbols.json identifies the applicable list when present.
Analysis boundary: The selected code and modeled external behavior that the analysis uses. Define it through concrete configuration and LLVM definitions rather than using "boundary" as an unexplained label for a count. Example: A selected function calling a NOP-modeled logger does not require the logger's original callees to enter P5.
Analysis harness: Code that invokes the activity's configured lifecycle and marks analysis inputs and outputs. It makes the execution context and observation points explicit to the analyzer. Example: A harness calls source markers, the activity step, and sink markers in the configured order.
Analysis model: The representation of software behavior used by the analysis. It must account for the relevant data dependencies, memory writes, control decisions, and whether a function returns to its caller. Example: A transfer model represents how a function's inputs affect its outputs.
Analysis review: The persistent Markdown review initialized and refreshed by STIG's Kotlin generator. It contains captured configuration facts, problem counts, sink worksheets, and preserved reviewer assessments tied to their evidence. Example: docs/analysis-reviews/activities/<activity>/analysis_review.md.
Analysis source: An input endpoint whose influence is traced in an analysis. This differs from a C++ source file. Example: A timestamp value marked by the harness as an input.
Analysis-equivalent behavior: Behavior that preserves the original function's effects relevant to the configured analysis. This requires evidence about those effects, even when the replacement contains fewer instructions. Example: Removing logging may be justified when its implementation cannot affect the analyzed outputs or relevant control flow.
Analyzer: The native STIG program that computes source-to-sink results from LLVM input and analysis settings. It is a separate program from the Gradle evidence collector and Markdown generator. Example: stig-code-analyzer.
Application binary interface: Compiler and platform conventions for function calls, parameter passing, returned values, and symbol naming. Acronym: ABI
Artifact: A produced file used as evidence. Example: llvm/p5/bitcode_rewrites.json.
Artifact hash: The content digest recorded for a particular artifact, together with its hash algorithm. Verify it against the file's bytes. Example: The payload's SHA-256 must match its manifest entry.
ASIL annotation: An interface annotation assigning an ASIL or QM classification to a compiled source or sink. Example: An ASIL B annotation for a specific payload field.
Automotive Safety Integrity Level: The automotive safety-integrity classification with levels A through D. STIG uses configured source and sink levels when selecting inputs for an analysis. It is separate from a problem's severity. Acronym: ASILExample: A sink can have ASIL B while its evidence check reports CRITICAL.
Blocker: A concrete unresolved condition preventing the next justified step. Name the wrong or missing evidence and the repair or additional evidence needed. Example: The configuration proposal omits a defined P3 function; correct that list before relying on the P5 application comparison.
Body shape: The implementation pattern expected or observed in a function's LLVM instructions. Final P5 validation uses expectedShape for the pattern requested by the configured rule. Example: A transfer body must still perform the relevant transfer after optimization.
Byte: The unit used to report a file's exact size. One byte contains eight bits. Name the artifact and whether it is current or retained from an earlier run.
Callee: A function invoked by a call instruction in another function. Example: If send() calls serialize(), serialize() is the callee.
Candidate edit: A proposed configuration change generated by the diagnostic. Check its supporting evidence before treating it as a required or accepted edit. Example: candidateEdits in review/transform_review.json.
Captured observation: A value recorded by a producer in the identified evidence. In report text, the word "captured" means that the value comes from those records rather than from a new assessment. Example: The problem count reports the identified evidence ZIP's records.
Cascading fault: Influence from a selected lower-ASIL source on a higher-ASIL sink under the cascading-fault analysis. It is a software-analysis observation, distinct from whether the pipeline displays it correctly. Example: A QM input influences an ASIL B output.
Check identifier: The stable name of the check reporting a problem, stored in problemId. Several affected items can fail the same check. Example: contradictory-transform-symbol-evidence.
Checkpoint: A specified moment in processing represented by retained files, so that their contents can be inspected and compared. Example: P5 immediately after recording applications and P5 after optimization are different checkpoints.
Chrono time point: A time value represented by std::chrono::time_point from the standard C++ time library. The other IsTimePointIncreased overload takes this type as its first parameter.
Collection completeness: Whether the required evidence for the requested collection mode was obtained. This describes the collected files, separately from completion of their review. Example: completeness in pipeline_status.json.
Collection status: The recorded outcome of the checks performed while gathering an activity's evidence. Identify the collection mode and the exact failing producer when describing this status. Example: status in pipeline_status.json.
Compilation unit: One source file together with its included headers, compiled under a particular compiler command. The resulting object file or LLVM module can contain many function definitions. Example: Compiling time_utils.cpp can produce both IsTimePointIncreased overloads.
Compiled leaf: A field-level interface endpoint discovered in compiled code. An annotation can label it but cannot create a missing endpoint. Example: A SourceLeaf or SinkLeaf function found in the LLVM module.
Compiler input: A source input supplied to a compiler operation. When reporting a total, state whether repeated commands for the same file count separately and which source categories are included. Example: Total P5 compiler inputs may include selected production units, a harness, model sources, and generated sources.
COMPLETE: The required evidence for the requested collection mode was collected. Semantic review and activity-specific reviews can still be pending. Example: A complete configuration-only evidence ZIP covers P1–P5, not the downstream analyzer and HTML stages.
Configuration-only collection: The stigCheckAnalysis mode selected by --configuration-only, collecting configuration and transform evidence through P5. It does not collect the P6, P7, and final-report evidence needed for full sink comparison. Example: <activity>-analysis-configuration-evidence.zip.
Configured final-body check: A check of one active rule whose kind is supported by the final-body validator. The JSON field checkedRuleCount counts these rules. addFunctionImplementation is not a NOP/no-return/transfer body-shape check. Example: Compare checked rules with surviving matches and separately accounted optimization removals.
Confirmation: Historical term for the transform review/acceptance enum. Current transform review uses one project registry reviewStatus per shared rule. Known-gap acceptance remains a separate engineering decision.
Confirmation fingerprint: Historical field confirmationFingerprint retained in older archives. It does not establish the current project registry reviewStatus.
CONFLICT: A generated LLVM classification indicating incompatible established behavior summaries among original exact functions covered by one selector. Different compilation-unit owners or SSA names, or UNKNOWN alongside one established summary, do not establish a conflict. Review may justify a common model or require exact selectors. Example: Two overloads require different modeled effects.
Contributing source: A selected source for which evidence establishes an influence on the sink under the analysis settings. Listing a source in the selected partition alone does not establish this.
Control dependency: Influence through a decision governing whether or how a later operation executes, rather than only through a copied data value. Example: An input determines which constant is assigned to an output.
Counting unit: The specific kind of item counted in a row. Counts with different units or overlapping membership cannot be added to obtain a problem total. Example: One rule can have two exact function applications; one rule can appear in both the unreviewed and stale-review rows.
CRITICAL: An execution or evidence-integrity problem that prevents producing or reliably interpreting the affected output. Available files may still be saved for diagnosis. Ordinary implementation gaps and unfinished transform reviews are HIGH when provisional output can still be generated. Example: Invalid LLVM prevents analysis, or generated evidence contains contradictory statements about an exact function.
Cross-stage evidence contradiction: An incompatible statement about the same exact function or rule in files produced at different stages. State the files, fields, and values that disagree, and distinguish an incorrect report from a missing or incorrect LLVM definition. Example: review/source_code_analysis_configuration.proposed.json omits the UpdateChannel P3 match, although llvm/p3/module.ll defines it and llvm/p5/bitcode_rewrites.json records its application.
Current confirmation fingerprint: Historical field currentConfirmationFingerprint. Current rule review uses reviewStatus without stored digests.
Current review fingerprint: Retired currentReviewFingerprint field. Current rule review uses the shared registry reviewStatus and explicit review of changed originals and models, without a computed review digest.
Data flow: Influence carried by values through computations, copies, or memory operations. Example: An input value is added to a constant and the result is assigned to an output.
Data-and-control-flow analysis: Analysis of input influence through both data operations and control decisions. In the review's data-flow table, the selected sources have equal or higher ASIL than the sink. Example: An input affects an output value directly or selects which value is assigned.
Deduplication: Grouping reports with the same problem identity so that repeated reports count once. It does not merge different affected functions into one root cause.
Demangled name: The readable C++ form decoded from a mangled name, normally including parameter types. Example: app::Send(int) is the demangled form of _ZN3app4SendEi.
Demotion to declaration: An LLVM operation that removes a function body while retaining its declaration. In source replacement this lets a selected replacement provide the definition during linking. Example: rewriteFunctionWithImplementation demotes matching original definitions from its selected original compilation unit.
Dependency: Code or data required by the selected implementation. For a called function, state whether the call belongs to original P3 evidence or to code actually included in P5. Example: A replacement send() calls serialize(), so the P5 input must account for that call.
Domain-specific language: A language designed for a particular kind of work. STIG's configuration language uses Kotlin functions and properties to describe a project and its analyses. Acronym: DSLExample: stigProject \{ bitcodeTransformRegistry \{ ... \} \} is part of STIG's Kotlin configuration language.
Entry point: The function from which execution is considered when analyzing the program. Example: The harness function selected as the analysis entry.
ERROR: A demonstrated disagreement for the reviewed sink or comparison. Identify the earliest differing producer and its evidence. The cell does not automatically create another CRITICAL problem group.
Evidence checker: Code validating produced files or comparing their recorded claims. Its problems must identify the actual value or LLVM content that violates the check. Example: evaluateP5TransformEvidence retains P3 matches and compares P5 input matches with P5 rewrite application records.
Evidence collector: A task gathering produced artifacts and check results into structured evidence for review. It can invoke consistency checks as part of collection. Example: stigCollectAnalysisConfigurationEvidence.
Evidence fingerprint: A digest calculated from the inputs relevant to a review assessment. A changed fingerprint indicates that the prior assessment needs to be checked against the new inputs. Example: A sink-cell fingerprint changes when its relevant module or settings change.
Evidence identity: The identifier distinguishing the evidence used for a review. State which evidence ZIP or set of files it identifies.
Evidence manifest: The evidence ZIP's index of payload paths, roles, producing tasks, sizes, hashes, schema, and version information. It establishes which files belong to the captured evidence. Example: evidence_manifest.json.
Evidence reference: A reference to the file and location supporting a reported fact. Where relevant, name the JSON field or exact LLVM symbol as well. Example: llvm/p3/module.ll: the define entry for UpdateChannel.
Evidence ZIP: The collected artifacts for one activity and requested collection mode. It preserves the producer's results for review. Having a ZIP does not establish that all its checks passed. Example: <activity>-analysis-configuration-evidence.zip.
Exact LLVM symbol: The precise identifier of one function, global, or alias in a module. Distinct overloads normally have distinct exact function symbols. State the symbol kind when counting. Example: The timestamp and chrono overloads of IsTimePointIncreased have different exact symbols.
EXACT_TRANSFERS: An LLVM classification identifying concrete dependency transfers. The transfer endpoints still need an appropriate explicit model; this label alone does not confirm one.
FAILED: The named check or stage did not meet a required condition. Read its reasons and files to identify the precise failure. Example: A comparison fails because its generated expected-function list omits a function defined in P3.
Feasibility: Whether the conditions needed for a candidate path can hold together under the analyzed model. Distinguish a potential dependency from a path shown feasible or infeasible by the available evidence.
Filed issue: An external ticket, such as a Jira or GitHub issue, tracking work on one or more findings. In a model, its IssueReference applies only to the object declaring it and to its specified rules, or all rules when the rule list is omitted. Filing a ticket does not resolve a finding or reduce its severity.
Final body-shape violation: The final-body checker found a surviving function whose body does not satisfy the requested shape. Count the affected exact functions and name the rule. Example: A requested transfer has collapsed into a body that performs no transfer.
Final HTML report: The rendered activity report shown in the browser and captured for review. The worksheet's Final HTML column refers to this report, not only the Markdown or table data used to build it. Example: Final vs analyzer checks whether the displayed result represents the analyzer result.
Final P5 bitcode: The optimized LLVM bitcode produced by P5 as input for the native analysis. P6 selects this bitcode or a recorded slice for a run. The bitcode file is module.bc; module.ll is its readable LLVM text. An application recorded before optimization does not guarantee that its separate function definition survives here. Example: Produced by stigAnalysisP5ProduceBitcodeTransformEvidence, validated by stigAnalysisP5ApplyBitcodeTransforms; archived text is llvm/p5/module.ll.
Final-body rule accounting: The rule accounting that combines final-body matches with rules accounted for by verified removals after optimization. It should cover the P5 input matched transform rules requiring final-body checks. P3-only rules are accounted for separately as absent from P5 input. Keep exact definition and alias counts separate. Example: A difference between final-body matches and checked rules needs explanation; the difference alone does not prove failed rewrites.
Finding: A result reported by a check or recorded during a review. A model-check finding identifies a reviewed object or source declaration, a rule, and its severity. A filed issue records the work needed to address it. Example: failureEvaluation reports that a particular Failure has no supported evaluation.
FLOW: An observed influence from the selected source partition to the named sink at a specified stage. It describes the software-analysis result, separately from whether later stages reproduce it correctly. Example: A correctly displayed cascading fault can have FLOW and an OK stage comparison.
FROM-CACHE: Gradle restored the task's outputs from its build cache.
Full collection: The normal stigCheckAnalysis mode requesting configuration evidence and the activity's analyzer/report chain. It can still be incomplete if a requested stage fails. Example: <activity>-analysis-evidence.zip.
Function body: The implementation instructions inside a function definition. Example: Inspect the instructions enclosed by a function's define entry in module.ll.
Function call: An instruction invoking a function. A call is a use of a function; it is separate from the function's declaration and its definition. Example: A call or invoke instruction naming an exact function in llvm/p3/module.ll.
Function declaration: A function entry supplying its name and type without its implementation in that LLVM module. State the checkpoint: a declaration in P3 does not by itself establish a missing required definition in final P5. Example: A declare entry in llvm/p3/module.ll.
Function definition: A function entry that supplies its implementation in the named LLVM module. A definition includes the function's signature and body. Its presence alone does not establish that it is called or affects a sink. Example: llvm/p3/module.ll contains a define entry for CalibrationValidator::UpdateChannel.
Function reference: A use of a function symbol in an instruction or stored value. A reference can be a call, but it can also store the function's address without calling it. Specify which kind of use the LLVM evidence shows. Example: A function-pointer table stores the address of app::Handle.
Function removed after P5 optimization: A function whose application is recorded before optimization and whose separate definition is accounted for as removed from final P5. The review records ELIMINATED_AFTER_P5_OPTIMIZATION. Earlier application evidence is required to distinguish this from an unexplained missing function.
Global declaration: An LLVM global entry naming an externally supplied object without defining it in the named module. Example: An external global entry in module.ll.
Global definition: An LLVM global entry that supplies the object's storage or value in the named module. Example: A global with an initializer in module.ll.
globaldce: An LLVM operation removing unused definitions. Use the actual before/after files and application records when attributing a missing final definition to optimization.
globalNamePattern: A selector for LLVM global variables or related compiler-generated globals. Its matching rules are separate from the qualified-name selection used for functions.
Gradle build script: A script configuring a Gradle project and its tasks. The Kotlin Gradle build scripts used by this project have the filename build.gradle.kts. Example: build.gradle.kts at the consumer root and one in each activity.
Gradle task: A named build operation. A full task path identifies both the project and the operation. Example: :activities:fusion_activity:stigCollectAnalysisConfigurationEvidence checks and collects that activity's configuration evidence.
HIGH: A major issue that probably makes an important result incomplete or misleading. The problem can still be collected, but the configured failure threshold determines whether it stops the build. Example: An active transform rule lacks current technical review, or a referenced function has no P5 implementation and the analysis proceeds provisionally.
Hypertext Markup Language: The document format used to describe the structure of a web page. Acronym: HTMLExample: The generated activity report.
INFO: An informational condition that is not a defect and requires no corrective action. It can explain a decision made by a task or analyzer. Example: A configured rule's function was accounted for as removed after optimization.
Initial LLVM module: The earliest untransformed compiled module retained for the review, built from the P2-derived ownership compilation inputs. It supplies original-code and ownership evidence; prebuilt library implementations can still be absent. Example: stigBuildFullLlvmOwnershipInventory; archived llvm/full/module.ll.
Interface annotation: Configuration assigning metadata to an already discovered interface endpoint. An entry that does not match a compiled endpoint can be ignored with a recorded problem.
Interface inventory: The list of compiled source/sink markers and their logical fields and metadata. Its entries are interface endpoints, not transform rules or function-application records. Example: stigExtractAnalysisInterfaceInventory; archived interface/inventory/analysis_interface_inventory.json.
Intermediate representation: A compiler's structured representation of a program between source code and target machine code. LLVM's representation records functions, instructions, globals, and metadata. Acronym: IRExample: LLVM IR can be encoded as LLVM bitcode (.bc) or LLVM text (.ll).
internalize: An LLVM operation making eligible symbols private to their module. It can enable later removal of unused definitions.
Inventory: A recorded list of a specified kind of item. Always state what is listed, the stage or scope, the file containing the list, and the counting unit. The bare word does not tell a reader whether the entries are rules, functions, source files, or reports. Example: "Exact functions matched in llvm/p3/module.ll" and "functions that triggered source-file inclusion" describe different lists.
Invocation: One Gradle execution that runs or reuses tasks and collects their evidence.
Invocation identifier: The value associating captured attempts and results with a particular Gradle execution. It is stored as invocationId in pipeline_status.json.
Known gap: An explicitly accepted cascading fault or missing expected flow declared for an activity. Its knownGaps declaration must match the current observation. A passing stage comparison does not itself record this acceptance. Example: knownGaps is the public Kotlin DSL block for these declarations.
Leaf: An individual field-level value in the logical interface. Example: header.timestamp.seconds within a topic payload.
Lifecycle: The configured sequence in which initialization, source marking, activity operations, and sink marking occur. Comparisons must use the same sequence and retained-state assumptions. Example: Construct the activity, mark inputs, run one step, and mark outputs.
Linked module: The LLVM module produced by linking compiled inputs. Its defined-function count is separate from the number of source files used to construct it.
Linked-module defined-function count: The number of function definitions in a named linked LLVM module. It is separate from the number of source files, active rules, declarations, or aliases.
Linking: Combining compiled LLVM inputs and resolving references between their symbols. Linking can join the definitions produced from many source files.
LLVM: The compiler infrastructure whose tools compile, link, inspect, and transform the code used by STIG's native analysis.
LLVM alias: An additional LLVM symbol referring to an existing definition. An alias does not supply another independent function body. Example: A constructor's C1 symbol can alias its C2 definition.
LLVM bitcode: The binary encoding of an LLVM module. In this workflow it is analysis input, not a runnable vehicle executable. Example: module.bc
LLVM endpoint: The exact compiled function or instruction representing an analysis source or sink for a particular run.
LLVM module: One collection of LLVM functions, globals, and metadata. A linked module can combine the compiled contents of many source files. Example: P3 and final P5 are different modules representing different checkpoints.
LLVM text: The text encoding of an LLVM module, used to inspect exact definitions, calls, and metadata. It is compiled evidence rather than the original C++ source. Example: Archived llvm/p5/module.ll shows the final P5 module in readable form.
LLVM trace: A supported explanation of how values and relevant control decisions in compiled LLVM lead from selected sources toward a sink. Merely locating a function definition or call is insufficient.
llvmDerivedBehavior: STIG's generated classification of original, untransformed LLVM behavior. It is supporting evidence, separate from the selected model and the activity review boolean. It is no longer an authored registry DSL argument and can be unavailable. Example: A concrete transfer model can have an LLVM UNKNOWN observation when the reviewer establishes semantics beyond the classifier's supported cases.
Logical interface field: The human-readable identity of a member exposed through a software interface. It can be mapped to a compiled analysis endpoint. Example: AvailabilityEstimatorResult.sensor_calibration_status.
Logical sink: The human-readable interface or field identity corresponding to a sink. Example: AvailabilityEstimatorResult.timestamp.
LOW: A minor, recoverable issue in the reported check. Read the affected item and explanation to understand its impact. Example: An unused interface-annotation entry is ignored because it does not match a compiled field.
Mangled name: The compiler-encoded name used to distinguish exact C++ functions, including overloads and compiler-generated variants. Example: _ZN3app4SendEi identifies app::Send(int) under the relevant C++ naming convention.
mangledSymbol: An optional selector restricting a function rule to one exact compiler-encoded symbol. The registry definition and activity use(...) entry must agree on the selector. Example: _ZN3app4SendEi is the compiler-encoded name of app::Send(int) under the relevant C++ naming convention.
Mebibyte: A file-size unit equal to 1,048,576 bytes, written MiB. Example: 2,097,152 bytes is 2 MiB.
Missing expected flow: An expected dependency from the selected source partition to a sink is absent under the configured analysis. Its explanation and acceptance are separate from transform-evidence consistency.
Missing or stale confirmation fingerprint: Historical wording for a missing or stale review fingerprint.
Missing or stale review fingerprint: Retired diagnostic for a missing or changed review digest. Current pending review is expressed by NEW or MODIFIED on the shared registry rule.
Missing recorded P5 application: A P5 input match for which the checker cannot find a corresponding P5 rewrite application after resolving aliases. The diagnostic field is missingApplications. A function present only in P3 does not establish this problem. This concerns the application record, separately from the final optimized body.
Missing registry definition: An activity has a use(...) entry, but the corresponding shared registry definition cannot be resolved. Example: A selector names app::Send, but no matching shared rule exists.
Missing required P5 definition: A function or global whose definition is required in final P5 but is unresolved under the P5 completeness checks. Missing implementations are HIGH and permit provisional execution below the configured failure threshold. They can hide data, control, or memory effects. A verified zero applies to this check only; it does not establish agreement of all generated reports or technical review of rules. Example: llvm/p5/unresolved_application_symbols.json.
Missing required use(...) entry: Evidence establishes that a rule is needed for the activity, but its activity selector is absent. Count required configuration edits separately from the functions affected by them. Example: One missing name-wide use(...) entry may leave two overloads without the required model.
MODERATE: A real issue that reduces quality or confidence while the affected evidence remains usable with an explained limitation. It should be corrected. Example: Incomplete optional metadata makes review harder without invalidating the main result.
N/A: The observation or comparison does not apply, with an explicit reason. Example: A particular analysis has no applicable source partition for this sink.
Name-wide function rule: A rule selected by qualifiedFunctionName without an additional exact mangledSymbol. Its model must be appropriate for every exact function matching that name. Example: One IsTimePointIncreased rule can match a timestamp overload and a chrono overload.
Native executable: A program compiled to machine code for its target platform. It is separate from the LLVM bitcode used by STIG's analyzer.
Native model source: An authored C or C++ source file implementing selected behavior for the analysis. The file is compiled into the analysis input. Example: A maintained .cpp file implementing an analysis model.
Native target: The executable or library selected from the original software build. Its build commands establish how the production code was compiled. Example: The target selected by the activity's nativeTarget configuration.
Native-target compilation-unit inventory: The recorded list of compilation units associated with the selected native target and its captured build. A count describes units in that list, not functions and not necessarily units selected for analysis. Name the compilation-command artifact used for the count.
No operation: Behavior that performs no relevant action. A STIG NOP model represents no relevant output dependency or side effect; it need not correspond to a literal machine-code NOP instruction. Acronym: NOP
No-return behavior: Function behavior that does not return normally to the caller. This is a property of the function, separate from the rule used to model it.
NO_FLOW: Evidence establishes no influence from the selected source partition to the named sink in the specified analysis scope. Missing evidence must not be represented by this value.
NO_RETURN: An LLVM classification stating that execution does not return normally from the examined function.
NO_TAINT_OUTPUT: An LLVM classification stating that the examined function has no output dependency relevant to the taint model. It is evidence for considering a NOP model, within the classifier's supported scope.
NOT_APPLICABLE: The named check does not apply to the item. It is not a passing result for an applicable check. Example: The NOP/no-return/transfer body-shape check does not apply to an addFunctionImplementation rule.
NOT_IN_P5_INPUT: The final-body review state for a configured rule with no P5 input match. There is no application to demand at that checkpoint. Review whether the activity still needs its use(...) entry; do not describe this state as a function removed after P5 optimization.
NOT_RUN: The named check did not execute. No result from that check has been established.
OK: Current evidence and the relevant analysis/model contract support the stated comparison. Record the supporting evidence. This assessment does not itself confirm a transform or accept a source-code gap. Example: P5 faithfully implements a justified model of the relevant P3 behavior.
Optimization: LLVM transformations that simplify the module while preserving the semantics required by the configured compilation and analysis. Optimization can remove a separate function definition, for example after its uses are eliminated. Example: A function recorded before optimization can be absent from final P5.
originalCompileUnit: The native compilation unit containing the original definition. It supplies original-definition evidence; rewriteFunctionWithImplementation also uses it to replace matching definitions before linking. The originalSource link defaults to this file.
Overload: One of several C++ functions sharing a qualified name but accepting different parameter types or lists. Each matching overload must be considered when reviewing a name-wide rule. Example: IsTimePointIncreased accepting a QPB timestamp and the version accepting a chrono time point.
ownerCompileUnit: Retired configuration property, replaced by originalCompileUnit. Recording an original compilation unit does not by itself retain the original implementation in P5.
Ownership evidence: Evidence identifying the compilation unit and source location of a function's original definition. It establishes where the definition came from, not whether the function affects a sink. Example: IsTimePointIncreased is defined by time_utils.cpp.
P1: The phase that runs or reuses the selected native build and captures its real compilation commands and input identity. Example: stigAnalysisP1BuildNativeTarget and stigAnalysisP1ExtractNativeCompileCommands.
P2: The phase that converts captured native compiler commands into commands for the configured LLVM toolchain. The source inputs are recompiled; a native executable is not translated into LLVM. Example: stigAnalysisP2ConvertCompileCommandsToLlvm.
P3: The stage selecting and compiling original definitions for ownership evidence, behavior review, and comparisons with transformed code. Example: stigAnalysisP3BuildProvenanceBitcode.
P3 bitcode: The LLVM bitcode containing the selected original compiled code produced by P3. Its readable LLVM text in .ll format establishes whether an exact symbol has a definition, declaration, or reference in that module. Example: stigAnalysisP3BuildProvenanceBitcode/module.bc; archived text is llvm/p3/module.ll.
P3 exact matched LLVM symbol: One exact function or global symbol present in stigAnalysisP3BuildProvenanceBitcode/module.ll and selected by an active activity rule. A match establishes presence and selection at P3, not that the symbol is missing or already transformed. Example: One name-wide rule may match two overload symbols in archived llvm/p3/module.ll.
P3-matched transform rule: One active rule with at least one exact P3 match. Count the rule once, even when it selects several exact symbols. Example: One rule, two P3 exact matched functions.
P4: The phase selecting the configured native implementation units for the analysis. This selection is distinct from collecting P3 transform-owner provenance compilation units. Example: stigAnalysisP4SelectSoftwareUnderAnalysis.
P5: The phase assembling the implementation code, analysis support, and configured transforms into LLVM input for analysis, with associated interface and run-plan evidence.
P5 evidence result: The evidence collector's result from comparing one rule's P5 input matches, P5 rewrite applications, and relevant validation records, while retaining its reported P3 matches separately. It is stored in p5Validation. It can fail on incorrect report data even when P5's own stage status is PASSED. Example: p5Validation=FAILED must be explained using its recorded reasons; it does not by itself establish a missing function body.
P5 final-module body-validation match: One active rewriteFunctionToNop, rewriteFunctionToNoReturn, or rewriteFunctionWithTransfer rule whose configured body shape is recognized in final P5 by stigAnalysisP5ProduceBitcodeTransformEvidence/bitcode_transform_validation.json. matchedRuleCount counts rules, not functions or applications. Example: Archived llvm/p5/bitcode_transform_validation.json.
P5 input: The LLVM module assembled from selected code, harness code, and model sources before post-link rewrites. Source replacements may already have been compiled into this module. It must not be described as wholly original production code. Example: stigAnalysisP5BuildUntransformedAnalyzerInput; archived llvm/p5-pre-transform/module.ll.
P5 input match: One exact function or global symbol selected by a configured rule in the linked P5 input before post-link rewrites. The generated p5InputMatchedSymbols list includes definitions, declarations, and function aliases. These matches determine the required P5 rewrite applications; reported P3 matches remain separate original-code evidence. Example: P3 defines several constructor overloads, but P5 input declares only the overload called by the selected code. Only that P5 input match requires an application.
P5 input matched transform rule: One active activity transform rule with at least one P5 input match. Count it once even when it selects several exact LLVM symbols. This count can differ from the P3-matched transform-rule count because the modules contain different selected code.
P5 rewrite application: One recorded application of an active transform rule to one exact LLVM definition at the application checkpoint. For addFunctionImplementation, this records the supplied implementation. The record is written before subsequent optimization. Count configured rules, exact definition applications, and alias symbols separately. Example: stigAnalysisP5ProduceBitcodeTransformEvidence/bitcode_rewrites.json; archived llvm/p5/bitcode_rewrites.json.
P5-provided source compilation unit: A source compilation unit included in P5 through a configured implementation/model source, separately from the native units selected by softwareUnderAnalysis. Name the source and the configuration that includes it. Example: A production .cpp supplied through addFunctionImplementation.
p5FinalBodyState: The per-rule description of final-body checking, including a recognized body, an accounted optimization removal, or a check that did not run or does not apply. It describes one part of the rule's evidence rather than its full review result. Example: An addFunctionImplementation rule has NOT_APPLICABLE for the NOP/no-return/transfer body-shape check.
P6: The stage executing native analysis on the exact selected LLVM input and recording source-to-sink results for the configured runs. Example: The review's Analyzer column describes captured P6 observations.
P7: The phase converting analyzer results and related evidence into diagrams, descriptions, tables, metrics, and report inputs. It is a separate stage from the final rendered HTML.
parameter(n): The zero-based position of an explicitly written C++ parameter in a transfer model. Hidden compiler parameters do not change this numbering. Example: parameter(0) is the first parameter written in the C++ declaration.
PARTIAL: Available evidence retained from an incomplete or failed collection attempt. The missing or failed stages must be identified before relying on the files.
PASSED: The named check or stage found no failure in what it validates. A passing result for one check does not establish that another check passed. Example: The P5 stage is PASSED while the later configuration-evidence comparison is FAILED.
Payload: An artifact included in an evidence ZIP and listed in its manifest. Example: The archived llvm/p3/module.ll file.
PhASAR: The framework used by STIG's native analyzer to perform static analysis of LLVM code. Name the actual P6-selected module when describing the input to a PhASAR analysis.
Pipeline: The connected sequence of compilation, transformation, analysis, and report-generation tasks. Example: The P1–P7 analysis pipeline and final HTML generation.
Problem: An issue reported by a defined check for a specific affected item. Investigation establishes its cause and required repair. Example: A generated report omits a function that its claimed P3 match list should include.
Problem category: The kind of issue recorded in the category field. TOOLCHAIN concerns STIG, the analyzer, or generated-evidence integrity; CONFIGURATION concerns user configuration and review; SOURCE_CODE concerns analyzed software; SPECIFICATION concerns requirements or safety-model content. Example: The two transform-evidence contradictions have category TOOLCHAIN.
Problem detail: Additional explanation stored with a problem, such as expected and actual values or the precise comparison that failed. Example: details in a problems.jsonl record.
Problem group: The reports sharing one problem identity. Count this group once, use its highest recorded severity, and retain its messages and evidence. Example: Two tasks repeat the same check failure for the same function: one group.
Problem identity: The four values identifying a reported issue: activity (projectPath), category, check (problemId), and affected item (subjectId). Different affected functions have different identities even when one tool bug caused their failures. Example: The same check reporting an issue for UpdateChannel and for one IsTimePointIncreased overload has two identities.
Problem message: The producer's description of what failed, stored in the problem record's message field. It should identify the incorrect value or code condition and the affected item.
Problem record: One structured report of a problem in STIG's shared JSONL format. It contains the activity, producer, category, check identifier, affected-item identifier, severity, message, and supporting details. Example: One StigProblemRecord written as a line in problems.jsonl.
Problem severity: The priority or seriousness assigned by a producer to a problem. It is distinct from a sink's ASIL, a task result, or an OK/ERROR review assessment. Example: CRITICAL, HIGH, MODERATE, LOW, INFO.
Producer: The exact task or component that generated the file or claim being discussed. Name it when locating the cause of incorrect data. Example: stigDeriveAnalysisConfiguration writes the configuration proposal used by the later evidence collector.
Producer version: The STIG version recorded as generating the evidence. Interpret the evidence ZIP using its schema and compatible workflow, not just the currently installed version. Example: 2.1.2-SNAPSHOT.
Production binary: An executable or library built for the deployed software. State which executable or library is meant when comparing it with analysis artifacts.
Project Gradle build script: The consumer's root Gradle build script. The shared transform rule definitions are authored in its stigProject \{ bitcodeTransformRegistry \{ ... \} \} block. Example: A rule can name app::fusion::IsTimePointIncreased and the production .cpp file supplying its implementation.
Project registry: The collection of shared transform rule definitions in the project's configuration. A rule being available here does not select it for every activity. Example: stigProject.bitcodeTransformRegistry
Project registry rule definition: One transform rule authored in the project's bitcodeTransformRegistry block. It specifies the selected function or global, the requested behavior, and associated configuration. Example: rewriteFunctionToNoReturn(qualifiedFunctionName = "amp::detail::assertion_failed", ...) is one rule definition.
projectPath: The activity or Gradle project to which a problem belongs. It is part of the problem's grouping key. Example: :activities:fusion_activity.
Provenance: Recorded information showing the origin of an artifact or function, such as its producing task, input files, compiler settings, or source location.
Provisional rule: A rule whose required behavior has not yet been established as an adequate concrete analysis model. Selecting the rule through use(...) does not resolve its behavior. Example: rewriteFunctionToUnknown identifies a function model that still needs review.
qualifiedFunctionName: A function's C++ name including its namespaces and class, but excluding its parameter list. Without mangledSymbol, a function rule uses this name to select every matching overload and compiler-generated variant. Example: app::fusion::validators::CalibrationValidator::UpdateChannel
Quality Management: The QM classification used for items without an assigned ASIL. STIG treats QM separately from ASIL A through D when forming source partitions. Acronym: QM
Reachability: Whether a function or instruction can be encountered from the configured entry points under the analyzed execution model.
Receiver: The object on which a non-static C++ member function is called. A transfer rule selects it with thisObject, separately from explicitly written parameters. Example: In validator.UpdateChannel(channel, status), validator is the receiver.
Regeneration: Running the generator again to refresh captured facts and preserve compatible reviewer edits. This cannot fix an incorrect claim that remains in the input evidence.
Repeated report: Another producer report with the same activity, category, check, and affected item as an existing report. Example: The same problem is emitted by two tasks.
Reported P3 matches: The generated list presented as a rule's exact P3 matches: manifest.activeTransforms\[\].matchedSymbols in the configuration proposal, and exactMatchedSymbols in the transform review. Check this list against actual P3 definitions when the reports disagree. Example: The proposal lists zero matches for UpdateChannel, but llvm/p3/module.ll contains its definition. The generated list is wrong.
returnValue: The transfer-model endpoint selecting a function's logical result. STIG resolves how the compiler represents that result, including a hidden result-storage parameter when used.
Review cell marker: An HTML comment beside a generated cell recording its stable identity and fingerprints. The generator uses it to preserve assessments and detect changed evidence. Example: Keep the stig-review-cell comment when editing the visible assessment.
Review fingerprint: Retired reviewFingerprint field. Current reviewStatus is recorded once per project registry rule; Git records changes and reviewers explicitly reopen affected rules.
Review generator: The Kotlin code rendering analysis_review.md from structured evidence while preserving compatible reviewer assessments. Example: stigGenerateArchivedAnalysisReview renders a review from extracted evidence.
Review notes: Reviewer-authored explanations, evidence references, and remaining work preserved with the analysis review.
Review status: The state of an assessment cell: OK, ERROR, UNASSESSED, UNAVAILABLE, STALE, or N/A. These states are separate from problem severities and from technical review of transforms.
reviewed: Retired activity-specific transform-review boolean. Current technical review is recorded with reviewStatus on the shared project registry rule. Known-gap acceptance remains separate.
reviewStatus: The shared project registry rule's technical review state: NEW, MODIFIED, or CONFIRMED. A used NEW rule emits a HIGH warning; a used MODIFIED rule emits a MODERATE warning. CONFIRMED records a completed semantic review, independently of generated LLVM observations and P5 validation.
Rewrite rule: A transform rule that changes an existing compiled function body or global definition, or replaces it with a configured source implementation. State the specific DSL operation when explaining what it changes. Example: rewriteFunctionWithTransfer replaces a function body with the configured dependency transfers.
rewriteFunctionToNop: A rule replacing a function body with a neutral implementation that models no relevant output dependency or side effect. A non-void function can still need a neutral return value. Choosing the rule requires evidence about the original function's behavior. Example: JSON kind REWRITE_FUNCTION_TO_NOP.
rewriteFunctionToNoReturn: A rule replacing a function body with an implementation that cannot return normally to its caller. Code after the call is unreachable through a normal return from that call. Example: A modeled fatal assertion handler.
rewriteFunctionToUnknown: An UNKNOWN function model recording that a concrete behavior model still needs to be established. It must not be read as a reviewed NOP or transfer model. Example: JSON kind REWRITE_FUNCTION_TO_UNKNOWN.
rewriteFunctionWithImplementation: A rule that supplies a replacement source implementation for functions from the specified originalCompileUnit. STIG removes the matching original bodies from that compilation input before linking the replacement. Example: A maintained analysis model replaces selected functions from a production .cpp file.
rewriteFunctionWithTransfer: A rule replacing a function body with an implementation of the configured dependency transfers. The endpoints specify the input and output values or memory involved. Example: A dependency from parameter(0) to returnValue.
rewriteGlobalToUnknown: An UNKNOWN global model whose required modeled definition or behavior remains unresolved. Example: JSON kind REWRITE_GLOBAL_TO_UNKNOWN.
rewriteGlobalToZero: A rule requesting a zero-initialized definition for a selected LLVM global in the analysis module. Its suitability depends on the role of that global in the analysis. Example: JSON kind REWRITE_GLOBAL_TO_ZERO.
Root cause: The underlying defect that explains one or more observed problems. Counting problems does not count independent root causes. Example: Using an incomplete expected-function list can produce two problems, one for each omitted function.
Rule identity: The value identifying one configured rule. For a function rule, it is its qualified function name, together with mangledSymbol when an exact function was selected. This differs from a problem identity and from a function's presence in a module. Example: One name-wide rule can cover two overloads of IsTimePointIncreased.
Rule kind: The operation requested by a transform rule. The JSON field kind records the enum value corresponding to the Kotlin DSL operation. Example: ADD_FUNCTION_IMPLEMENTATION corresponds to addFunctionImplementation(...).
Rule semantics: The behavior requested by a particular configured transform rule. Review compares that requested behavior with the relevant behavior of the original function. Example: A transfer rule requests a dependency from parameter(0) to returnValue.
Run identifier: The value identifying one analyzer run and its associated files. Captured run data use the field runStem for this identifier.
Run plan: The description of the analyses to execute, including their sources, sink, module, and settings.
Schema: The declared structure and version of a machine-readable evidence format. Example: schemaId and schemaVersion in JSON.
Secure Hash Algorithm (256-bit): The hash algorithm used to calculate the recorded 256-bit digest of an evidence file's bytes. Matching digests support file-identity checks; they do not validate analysis conclusions. Acronym: SHA-256
Selected P6 module: The exact LLVM file used by one analyzer run. A P5-to-analyzer comparison must identify this file and any changes made when selecting it. Example: selected_p6_modules.json maps run identifiers to captured .bc and .ll files and hashes.
Selector: The configured name or exact symbol used to choose functions or globals for a rule. A selector can match zero, one, or several items in a particular LLVM module. Example: A qualified function name can select every overload with that name.
setBy: Historical authored transform metadata distinguishing MANUAL and LLVM ownership. The current transform DSL removes this flag and import preserves every existing registry definition. Other APIs may independently use a field with the same name. Example: A retained older ZIP can contain setBy = MANUAL; report it as captured historical metadata.
Sink: An analysis output endpoint whose contributing inputs or fault influences are examined. Every captured sink has a row in each review table, including when a cell is unavailable or inapplicable.
Sink marker: A harness function marking an output at which source influence should be examined. Example: harness::SinkLeaf marks a field-level sink.
SKIPPED: Gradle reported that the task did not execute its work. This does not supply a passing analysis result.
Slice: A reduced LLVM module prepared from a larger module for a specified analysis scope. Example: A P6 run can use a recorded slice instead of the complete final P5 module.
Software signal: An input or output value exchanged by the software. A function processing a signal is a different item from the signal itself. Example: sensor_calibration_status is an output value; UpdateChannel(...) is a function.
softwareUnderAnalysis native compilation units: The native source units explicitly selected through the activity's softwareUnderAnalysis configuration to contribute real implementation code to P5. Count these separately from transform-owner provenance compilation units and analysis-support sources.
Source file: A file compiled as part of the software or its analysis support. The word "source" here refers to code, whereas an analysis source is an input whose influence is traced. Example: domains/avae/common/time_utils/time_utils.cpp
Source inclusion trigger: An exact unresolved symbol that caused a source-providing rule's source file to be included while selecting the required implementation source files. It explains why a file was included; P3 exact matched LLVM symbols are resolved separately from P3 bitcode. Example: A call to one IsTimePointIncreased overload can cause time_utils.cpp to be included. Compiling the file can supply both overloads. The proposal records sourceInclusionTriggers separately from matchedSymbols.
Source marker: A harness function marking a value as an analysis input whose influence should be traced. Example: harness::SourceLeaf marks a field-level source.
Source partition: The sources selected for a particular sink and analysis kind. Selection establishes which inputs are considered, not which ones actually influence the sink. Example: The data-flow comparison selects equal-or-higher-ASIL sources; the cascading-fault comparison selects lower-ASIL sources.
Source-inclusion trigger list: The exact unresolved function symbols that made stigDeriveAnalysisConfiguration include a source file. This calculation records why a file was added. It does not enumerate every function later defined by compiling that file. Example: One IsTimePointIncreased overload triggers inclusion of time_utils.cpp; the file also defines the other overload.
Source-providing rule: A rule that supplies a source file to be compiled for the analysis input. Its compilation unit can introduce additional function definitions and calls. Example: addFunctionImplementation and rewriteFunctionWithImplementation.
sret: An LLVM parameter attribute identifying caller-provided storage for a returned value. This hidden compiler parameter does not participate in the numbering of explicit C++ parameters. Example: A function returning a structure can write the result through an sret parameter.
Stage: One named part of the pipeline, which can contain several tasks. Example: P5 constructs and checks the LLVM input for analysis.
Stage cell: A worksheet cell displaying the observation or assessment availability for one sink at Initial LLVM, P3, P5, Analyzer, or Final HTML.
Stage comparison: An assessment of corresponding sink observations at two stages using the same source partition and analysis assumptions. Example: P5 vs P3.
Stage observation: The supported result for one sink at one checkpoint, including its source influence or reachability state.
STALE: A previous review assessment refers to evidence superseded by changed modules, configuration, settings, or outputs. The old assessment needs to be checked against the new evidence.
STIG consumer project: A project that uses the STIG Gradle plugin to configure analyses of its software and generate reports. Its configuration is separate from the source code implementing STIG itself. Example: stig-project consumes the sibling stig tool checkout.
Stub: A simplified implementation standing in for a function or component during analysis. Its relevant effects need justification; being a stub does not automatically make a NOP appropriate.
Synthesized source compilation unit: A compilation unit generated by STIG for a specific analysis purpose. Count it separately from authored production or model files. Example: A generated harness compilation unit.
Taint: An analysis label propagated from selected inputs to track their influence. It does not mean that the concrete runtime value is corrupt or malicious. Example: A source's taint reaches a sink through arithmetic and assignments.
Task outcome: Gradle's execution state for an operation. It describes whether the task ran or reused outputs, separately from the analysis conclusions written into those outputs. Example: A task can successfully export files that record a failed analysis check.
Timestamp parameter: A function parameter carrying an application timestamp value. Example: app::common::Timestamp is the first parameter type of one IsTimePointIncreased overload.
Transfer body shape: The shape named passthrough by the final P5 body checker. It checks that the produced body performs the configured transfer; it does not establish that choosing that model was correct. Example: expectedShape=passthrough.
Transfer endpoint: A named input or output used in a transfer model, such as an explicit parameter, receiver object, or return value, with any configured memory access. Example: parameter(0), thisObject, returnValue
Transfer model: An analysis model describing how dependencies propagate between specified inputs and outputs. Example: An input value affects a function's return value.
Transform inventory fingerprint: Retired transformInventoryFingerprint field. Current evidence compares rule identities, kinds and exact LLVM application records directly.
Transform review: Examination of a shared rule against original exact matches in the complete initial LLVM module, relevant callers/callees, globals and outputs, affected activity sinks/lifecycle and current P5 results. Record the justification in reason and completed review as reviewStatus = CONFIRMED on the project rule.
Transform rule: One configured operation used to construct analysis input. A rule can replace compiled behavior or supply implementations by compiling a source file. It is authored in the project Gradle build script and selected through an activity's use(...) entry. Example: addFunctionImplementation supplies real code; rewriteFunctionToNop replaces a function body.
Transform-owner provenance compilation unit: A native compilation unit retained without rewrites in P3 to provide the original definitions for selected transform rules. Count these units separately from the units selected by softwareUnderAnalysis.
Transition cell: A worksheet cell containing the status and supporting assessment of a stage comparison. Example: The cell under Analyzer vs P5 for one sink.
UNASSESSED: Required inputs exist, but the necessary trace, comparison, or effect justification has not been completed. Example: A readable P3 module is available, but this sink's dependencies have not been reviewed.
UNAVAILABLE: Evidence needed for this observation or comparison is missing. This is not a verified zero or a negative flow result. Example: A configuration-only evidence ZIP lacks the captured P6 result.
UNCALLED: Evidence establishes that the named function is not called in the specified analysis scope. A missing result alone is insufficient.
UNCONFIRMED: Historical transform-confirmation enum value. Current shared registry rules start with reviewStatus = NEW.
Unexpected P5 application: A P5 rewrite application that the checker cannot associate with its P5 input matches after resolving aliases. The diagnostic field is unexpectedApplications. Check the application record and llvm/p5-pre-transform/module.ll before concluding which is wrong. A function introduced by the harness can match P5 input without being present in P3. Example: bitcode_rewrites.json records applying the configured rule to UpdateChannel, while the generated P5 input match list is empty.
UNKNOWN: A generated LLVM classification indicating insufficient evidence to derive supported behavior. It is not a claim of absent effects and is separate from an UNKNOWN model and a shared rule awaiting review.
UNKNOWN model: A rewriteFunctionToUnknown or rewriteGlobalToUnknown rule whose concrete modeled behavior is unresolved. It cannot have reviewStatus = CONFIRMED. Historical documents may call this a provisional rule.
Unmatched final-body check: The final-body scan did not recognize a function for a checked rule. Application records and optimization evidence are needed to distinguish an accounted removal from a failed or unexplained application.
UNREACHED: Evidence establishes that the named analysis point is not reached in the specified scope. Missing output or a missing marker alone does not establish this state.
Unresolved application symbol: An application function or global that the named analysis module requires but does not define. State the exact symbol, checkpoint, and completeness-check result. Explicitly allowed external runtime symbols are accounted for separately. Example: llvm/p5/unresolved_application_symbols.json lists required definitions still missing from final P5.
Unreviewed transform rule: An active rule whose shared project registry definition has reviewStatus = NEW or MODIFIED. Its model can already be concrete; its technical review is pending.
Unselected registry rule: A shared rule for which the activity has no use(...) entry. This is normal unless evidence demonstrates that the activity requires it. Example: A second activity's transform rule may be available in the same registry while remaining unselected by another activity.
Unset metadata: A metadata field for which no value was recorded. The display text none or JSON value null can represent this absence. An absent llvmDerivedBehavior value is not the classification NO_TAINT_OUTPUT. Example: A source-supplying rule shows llvmDerivedBehavior=none in the review and null in JSON.
UP-TO-DATE: Gradle reused existing task outputs because their declared inputs and outputs met its up-to-date checks.
USER_CONFIRMED: Historical transform-confirmation enum value for human acceptance. Current transform review has no separate human acceptance flag; it uses the shared project registry reviewStatus.
Validation gate: A named check that must pass before relying on a stage for the next part of the workflow. Name the check rather than saying only that "the build passed." Example: stigAnalysisP5ApplyBitcodeTransforms validates the P5 producer result.

23 October 2026