Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.firstresonance.io/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

A redline is an in-flight modification to a procedure made during a specific run. The shop floor is the place where the as-designed procedure meets actual hardware, and reality often differs from the plan: a step needs to be split, a field needs a new measurement, an instruction was wrong, a step is missing entirely. Redlines are how you capture those deviations without either:
  • Editing the procedure template (which would change every other in-flight and future run), or
  • Losing the audit trail of what actually happened (which would break traceability).
A redline lives on the run, not the procedure. It’s tracked, reviewable, and can be reconciled back into the procedure template later if the change should be permanent.

​
When to use a redline vs an issue

These two are easy to confuse:
Use a redline when…Use an issue when…
The procedure needs to change for this run (add a step, modify a field, correct an instruction)The part has a problem (nonconformance, defect, supplier issue)
The change is procedural — what work happens, in what orderThe change is dispositional — what to do with affected material
You want to update the procedure template afterwardYou want to disposition (use as is / rework / scrap) the affected unit
Redlines and issues often go together — an issue might trigger a redline (the step missed something; we need to add a verification step). Both are recorded, both have reviewers, both contribute to the build’s history.

​
Redline mechanics

A redline is a JSON-encoded patch that describes one or more changes to the run’s steps. Common patches:
  • Add step — insert a new step at a position in the run’s order.
  • Duplicate step — copy an existing step (often used when an operator needs to repeat an inspection on a different feature).
  • Modify step — change a step’s instructions, add a field, change a validation.
  • Reorder steps — move a step earlier or later in the run.
  • Remove step — mark a step as not-applicable for this run (rare, but used when a procedure assumed a feature that the actual unit doesn’t have).
Each redline carries:
  • Author — the operator or engineer who created it.
  • Reason — free text explaining why.
  • Status — Open (proposed) or Closed (accepted / rejected).
  • Approval gate — closure typically requires a gate (e.g. ME or QE sign-off).

​
Creating a redline

From the run page:
  1. Open the step that needs modification (or the step preceding the insertion point).
  2. Click Redline.
  3. Choose the patch type (add / duplicate / modify / reorder / remove).
  4. Make the change in the redline editor.
  5. Add a reason.
  6. Submit.
The redline lands in Open state. ION applies the change to the run immediately — operators see the new state — but the redline itself awaits closure approval.

​
Step duplication mid-run

A common pattern: an inspection step that needs to be repeated on a different feature of the part. Instead of editing the procedure or hand-waving the second inspection, duplicate the step as a redline:
  1. From the step you want to duplicate, click Redline → Duplicate step.
  2. ION inserts a copy of the step right after the original, in todo state.
  3. The new step has the same fields and validations; the operator fills it in fresh on the new feature.
The duplicated step has its own ID, sign-off, and audit trail — it’s a first-class run step, just one that wasn’t on the original procedure.

​
Merge behavior and step reordering

When a redline modifies the order of steps, ION enforces a few invariants:
  • Already-completed steps don’t move. If step 5 is complete and you try to insert a new step at position 3, the new step goes after step 5 in the executed order even if its position number is 3. Audit history reflects when each step was actually done, not where it sits in the procedure.
  • Open steps shift. Subsequent todo and in_progress steps renumber to accommodate the insertion.
  • References stay stable. Build requirements and field IDs don’t change on reorder — only the rendered position.
This means a redline that reorders a sequence won’t rewrite history. Operators who already finished step 5 don’t see their work move.

​
Redlines on batched runs

Runs that are part of a run batch propagate certain changes across siblings. Redlines have specific propagation rules:
  • By default, redlines are run-local. Adding a step to one batched run doesn’t add it to siblings.
  • Promote-to-batch — a redline can be explicitly promoted so the same change applies to every sibling in the batch. Useful when the entire batch shares the redline’s reason (e.g. “all units in this lot have feature X that requires an extra inspection”).
  • Already-completed sibling steps don’t get retroactively modified. If you promote a redline that adds a step at position 3, but a sibling has already passed position 5, that sibling does not retroactively gain step 3.
Promote sparingly. A redline that’s promoted to a whole batch is effectively a procedure change for that batch. If the change should also apply to future batches, that’s a procedure revision, not a redline.

​
Closing a redline

When the run is reviewed (typically at completion, or earlier for high-impact redlines), open redlines are closed:
  1. The reviewer (per the redline’s approval gate) opens the redline.
  2. They mark it Closed — the redline is now part of the run’s permanent record.
  3. Optional: they file a procedure-revision proposal if the change should be folded back into the template for future runs.
Closed redlines are immutable. Reopening one requires admin permission and leaves an audit entry.

​
Standard step conversion edge cases

A few cases that confuse operators:
  • Duplicating a step that has already partially executed — ION duplicates the step template, not its execution state. The new step starts fresh in todo regardless of the source step’s status.
  • Modifying a field on a step where another operator already filled the field — ION protects the existing value. The redline modifies the field’s configuration (validation, label, required-ness) but doesn’t overwrite a captured value.
  • Removing a step that has installations — blocked. You’d need to first revert the installations (or, more commonly, mark the step failed instead of removing it).
When in doubt, the conservative path is to fail the step with an issue and disposition the affected material — that captures the same information without modifying the procedure structure.

​
Tips

  • Write the reason for the operator who reads it next. “Added inspection per Joe” is useless six months later; “Added 2nd torque check on aft fastener — first version’s procedure missed the duplicate hardware” is reusable.
  • Don’t redline what should be a procedure revision. If the same change keeps recurring across runs, escalate to engineering and revise the procedure. Redlines are for this build; revisions are for the future.
  • Close redlines at run completion. Open redlines in a completed run are an inconsistent state. Reviewers should close them as part of the run-completion review.
  • For batch runs, check the propagation flag carefully. Most redlines are run-local; promoting incorrectly multiplies the impact across many builds.