Skip to main contentSkip to navigation
Veldarium
Work with us

Use case · Engineering

Change impact

Engineering change management, followed past the drawing: when a configuration change is released, trace it to the work, material, inspection and schedule it actually affects. Mark honestly what cannot be traced.

Inject the change and watch it travel
  • Records
  • Released work
  • Physical build
  • Human authority

What happensA design revision lands after fabrication has started. Material, work packages, inspections and the next blocks may all inherit it.

  1. The route is re-released, Records

    CFG-029 moves DR-118 from Rev C to Rev D on the seawater-cooling route, while the crew is at the bench.

  2. The reach is traced, Records

    Every governed object related to the drawing family becomes a candidate. Related-with-no-assessment is its own state, never a quiet "unaffected".

  3. Released work is re-evaluated, Released work

    Two objects it reaches are affected and must be re-evaluated before release (work package and material). One is known not affected, because an assessment cleared it. One has no assessment and stays impact not established.

  4. The consequence reaches steel

    Steel is already cut, Physical build

    Material cut to Rev C is either still good or is rework, and nothing at the bench looks different either way.

  5. Configuration authority decides, Human authority

    What proceeds, what is re-released at Rev D, and what comes back out. The impact set is evidence for that call, not the call.

What it costsA superseded definition can reach material, fabrication, inspection, or schedule before its downstream consequence is recognized.

How VeldBuild answers it

What did CFG-029 affect? And what did it explicitly not affect?

What it reads

Scope
The declared Build Graph neighborhood of one change: affected configuration objects, work packages, material, inspections, and schedule dependencies.
Records
Engineering change notice and revision lineage · Work packages written against the affected object · Material specified at the prior revision · Inspection and acceptance criteria · Downstream schedule dependencies
Evidence it needs
Change notice · Revision lineage and supersession edges · Affected work-package references · Affected material and inspection records

What it computes

Steps
  • Follow the change to everything it is declared to touch
  • Call nothing affected or not affected without evidence
  • Keep an unmodeled or unverified relation as impact not established
Output
What the change reaches, what it does not, and what nobody has assessed yet, each with an owner.

What stays with people

Left unknown
  • An unmodeled dependency
  • Missing applicability or effectivity evidence
  • An affected object without completed disposition evidence
Decided by
  • VeldBuild reports affected, not affected, and impact-not-established; it does not invent a relation it cannot trace
  • Engineering dispositions the change and everything it leaves unresolved

What would prove it on real records

Test
Run it against a controlled slice of real PLM dependencies and measure, on reviewed changes, what it found, what it missed, what it left open and how dispositions closed.
  1. Which affected objects still need action, and who owns them?
  2. Where is the impact simply not established from the available data?

If your team answers this by hand, start with one work area.

Email the release decision, the systems that hold its records, and who owns it. Keep the first message non-confidential.

chris@veldarium.com