Valve Traceability | AseptSoft Documentation

Valve Traceability keeps each valve's per-step open/closed states attached to the right valve as your drawings evolve — through copy/paste, file rename, offline edits, tag changes, and tag swaps between two valves. Instead of silently losing or transposing the configured behaviour every time the drawing changes, AseptSoft recognises what happened, applies the safe default, and tells you about it — with a single-click reversal if the default isn't what you wanted, and a complete audit log so you can defend the decision later.

Access: Use the Migration Inbox, Orphan Functions, and other Traceability commands from the Module Ribbon's Traceability section, or run them from the AutoCAD command line.

🔄 What kinds of changes are tracked

Scenario	Default behaviour
📋 Copy-paste a valve inside the same module	Geometry copies; the new valve gets a fresh, blank function (you almost always want a new behaviour for the new entity).
📦 Copy-paste a valve from another module	Geometry copies; the function (per-step states) is migrated along with it (you almost always want to reuse the source's behaviour).
🪪 Rename the DWG file	Recognised automatically — the valves keep their functions on the renamed drawing.
🗂️ Clone a DWG outside AutoCAD	Recognised on next open — the cloned drawing's valves don't conflict with the originals.
💻 Edit a DWG offline	On next open, AseptSoft reconciles added/removed/remapped entities.
🏷️ Change a valve's tag	The function follows the valve, not the tag.
🔁 Swap tags between two valves	Recognised as a swap; functions stay with their original valves (or with the tags, depending on confidence and your preferences).

Each scenario is detected by AseptSoft and turned into a migration decision with a confidence score. High-confidence decisions apply silently. Medium-confidence ones surface a small toast in the bottom-right corner with a single-click revert. Low-confidence ones show up in the Migration Inbox for you to review.

🔔 The migration toast

When AseptSoft applies a medium-confidence migration — for example, a same-module paste it heuristically resolved as "fresh function" — a small non-modal card appears at the bottom-right of AutoCAD.

Element	What it shows
Title	A short description of what happened ("Pasted V-201 — assigned a fresh function").
Detail	Source and target tags, the scenario detected, the confidence score.
Revert button	Single click to undo the migration and restore the previous state. Available for 15 seconds, then the toast auto-dismisses.

The toast is non-blocking — it floats on top of AutoCAD without stealing focus or interrupting work.

📥 The Migration Inbox

When AseptSoft is genuinely unsure what to do with a paste, rename, or offline edit (e.g. two near-identical valves in two different drawings, both with the same tag), the decision is queued in the Migration Inbox instead of being applied silently.

Access: ASEPTSOFTMIGRATIONINBOX command.

The inbox lists every pending decision with:

Column	Meaning
When	Timestamp of the change AseptSoft detected.
Scenario	The detected scenario (paste, rename, tag swap, …).
Source / Target	Tags and PIDs of the entities involved.
Confidence	The score AseptSoft assigned.
Proposed action	What the default decision was.
Decide	Accept (apply the proposed action), Reject (do nothing), or Customise (pick a different mapping).

Decisions stay in the inbox until you act on them. Closing the window doesn't lose the queue; it persists until each item is resolved.

🗑️ Orphan Functions

When a valve disappears from the drawing — deleted, renamed beyond recognition, or moved to a drawing AseptSoft can't reconcile — its per-step function is moved to the Orphan Functions registry instead of being silently retained or silently lost.

Access: ASEPTSOFTORPHANFUNCTIONS command.

The window shows every orphaned function with:

Column	Meaning
Tag	The original valve's tag.
PID	The drawing it came from.
States	A summary of the per-step states the orphan still carries.
Created	When it became an orphan.
Action	Adopt (re-attach to a chosen valve), Discard (drop it now), or Wait (do nothing).

Orphans are kept for 30 days by default and then auto-purged. The retention is configurable in the Traceability settings.

📚 Audit log

Every migration — whether silent, toast-confirmed, or inbox-decided — appends a row to the project's Migration Audit Log with:

The scenario detected
The before/after state
The confidence score
The user who applied or accepted the decision
The timestamp

Pharma audits routinely require an explanation of why a P&ID's behaviour changed. The audit log answers that question without anyone having to reconstruct it from memory.

🔁 Manual traceability commands

Beyond the automatic detection, the Traceability section adds command-line tools for explicit valve-function operations.

Command	Purpose
`ASEPTSOFTCOPYFUNCTION`	Copy the function (per-step states) of a selected valve to a shadow clipboard.
`ASEPTSOFTPASTEFUNCTION`	Paste a previously-copied function onto another valve.
`ASEPTSOFTTRANSPOSEFUNCTION`	Swap the functions of two valves (the common "retag swap" case made explicit).
`ASEPTSOFTREMATCH`	Re-run reconciliation against the project — useful after manual fixups.
`ASEPTSOFTUNDOLASTMIGRATION`	Reverse the last migration that was applied (toast or inbox).

⚙️ Traceability modes

A project-wide Traceability Mode setting controls how aggressively AseptSoft acts on its own decisions.

Mode	Effect
🟢 Silent	Apply every confidence tier silently. No toasts, no inbox queue.
🔵 Balanced (default)	High-confidence silent; medium-confidence toast; low-confidence inbox.
🟠 Strict Review	Everything except the highest-confidence cases queues to the inbox for explicit review.

Each project can set its own mode based on how regulated the workflow is. A high-stakes pharma master P&ID typically runs Strict Review; a working design draft typically runs Balanced.

🏭 Pharma example: retagging a row of CIP valves

You've decided to renumber the valves on a CIP supply header from V-201..V-208 to V-301..V-308 to match a new naming convention. Each valve has accumulated days of per-step state configuration; you don't want to lose any of it.

You change the tags on the drawing.
AseptSoft detects each tag change. Because no two changes look like a swap and the geometry / position of each valve is unchanged, the confidence score is high. The functions migrate silently and a single summary toast appears: "Renamed 8 valves; functions preserved."
You realise you accidentally renamed V-205 to V-307 instead of V-305. You change it back to V-305.
The audit log shows the chain of changes. The Migration Inbox is empty (every decision was high-confidence). All 8 valves have their per-step states intact under the new tags.

If a step had gone differently — say the rename was so drastic that AseptSoft couldn't tell which old valve the new tag corresponded to — the function would have ended up in the Orphan Functions window, and you'd have a 30-day window to Adopt it back onto the right valve.

State — what the per-step "function" actually contains.
Status Editor — the Valve × Step matrix where functions are typically authored.
Version Control — saving and merging across collaborators.