Glossary

    The engineering terms we use, defined.

    Every term we use on the site, defined in two sentences, with the page where it matters.

    Baseline

    A frozen, approved state of a configuration at a given milestone, used as the reference for every later change. In Koddex a baseline is a locked version of the configuration that you can compare with any other.

    Controlled releases & baselines
    BOM (EBOM, MBOM)

    The bill of materials lists the parts, quantities and structure of a product; the EBOM is the engineering view, the MBOM the manufacturing one. In Koddex both views read the same items, so a change made in one shows in the other.

    BOM management
    Change request (ECO)

    A formal proposal to modify an approved configuration, with its rationale, its impact and its approvals. In Koddex the change request carries its computed impact and keeps the decision on the items it touches.

    Impact analysis
    ConOps

    The concept of operations describes how the system will be used, by whom and in which environment, from the stakeholders' point of view. It is the reference that validation checks the finished system against.

    The V-model, accelerated
    Digital thread

    The connected record of a product's data across its lifecycle, from requirement to design, test and operation. In Koddex, requirements, parts and tests are stored as linked items, so the links between them are looked up instead of rebuilt by hand.

    Koddex Forge
    IADT

    The four verification methods of systems engineering: inspection, analysis, demonstration and test, from the cheapest to the most conclusive. Every requirement declares which one will prove it.

    The V-model, accelerated
    Impact analysis

    The identification of everything a proposed change affects before it is approved: requirements, parts, tests, variants and deliveries. In Koddex it is computed automatically from the links between items.

    Impact analysis
    Koddex Forge

    The data platform that Koddex products run on: it holds millions of linked requirements, components and test results, sets access rights per user and per partner, traces every change, and lets each team define its own data model. Thread is the first product built on it.

    Koddex Forge
    MCP

    The Model Context Protocol is an open standard that lets AI assistants call tools and read context from other systems. Through MCP, assistants such as Claude or ChatGPT work on Koddex data within the user's permissions.

    API guide
    N² matrix

    A square matrix with the system's elements on the diagonal and their interfaces in the other cells, read from row to column. It makes every interface explicit before integration starts.

    The V-model, accelerated
    Requirements management

    Capturing, structuring, allocating and verifying what a system must do, and keeping each requirement linked to what implements and proves it. Coverage tells which requirements still have no verification.

    Requirements management
    Review gates (SRR, PDR, CDR, TRR, SAR, ORR)

    The formal reviews that close each phase of a programme: system requirements, preliminary design, critical design, test readiness, system acceptance and operational readiness. In Koddex each gate is frozen as a baseline.

    The V-model, accelerated
    Traceability

    The ability to follow a requirement to the design that implements it, the test that verifies it and the result that proves it, and back. Audit-ready traceability is that chain kept current as the work happens.

    Audit-ready traceability
    V-model

    The systems engineering lifecycle drawn as a V: definition and decomposition down the left branch, integration and proof up the right, each level verified against its counterpart. It frames most certified hardware programmes.

    The V-model, accelerated
    VCRM

    The verification cross-reference matrix lists every requirement with its verification method, the evidence that proves it and its status. In Koddex it is generated from the requirements and stays current, so nobody rebuilds it before a review.

    The V-model, accelerated
    Verification vs validation

    Verification checks the product against its specification; validation checks the specification against the stakeholder need. A product can pass every verification and still fail validation.

    The V-model, accelerated