Calibration & Alignment
This topic sits at the point where machine software stops being “move to X/Y/Z” and starts dealing with physical truth.
A business system can often assume that if a record says a value is 10, then 10 is 10. A machine cannot. In a real machine, the stage may be slightly shifted, the camera may not be mounted exactly where CAD says it is, a tool may have been replaced, thermal expansion may change geometry during the day, and the workpiece itself may not be sitting exactly where the machine expected. So the software must continuously answer a harder question:
Given the real physical condition of this machine right now, where is the target actually, and how should motion and process commands be corrected?
That is why “Calibration & Alignment” exists in Domain 1. It is part of the machine control and motion problem, specifically around coordinate correction, offsets and transforms, alignment flows, drift, and re-calibration.
PART 1 — WHY CALIBRATION & ALIGNMENT EXIST
A machine is built from mechanical parts, sensors, cameras, actuators, fixtures, and software models. None of those line up perfectly just because the machine was assembled carefully.
Even in a very precise machine, software cannot rely only on nominal positions.
Why?
Because nominal design says things like:
- the camera center is here
- the nozzle tip is here
- the wafer notch should be here
- the stage origin should be here
But the real machine says:
- the camera is mounted with small offset and slight rotation
- the tool was replaced and sits 80 microns differently
- the wafer loaded a little off-center
- the stage home sensor is repeatable, but not the actual process origin
- temperature changed the geometry enough to matter
So the software needs trusted relationships between:
- the axes
- the camera or sensor
- the tool or end effector
- the workpiece or product coordinate frame
Without that, motion can still “work,” but the machine will be accurate only by accident.
Example 1: Wafer stage under inspection optics
A stage moves a wafer under a camera. The recipe may say “inspect die at wafer coordinate (X, Y).” But the machine controller only knows motor/encoder position in stage coordinates. The camera sees image coordinates. The wafer itself may be rotated slightly. Calibration and alignment bridge those worlds.
If that bridge is weak, the stage moves to a mathematically valid position that is physically wrong.
Example 2: Camera-guided pick-and-place
A camera detects part location. The robot must move the gripper to that part. The camera is not the gripper. So software must know the transform from camera frame to robot/tool frame, plus any active part alignment correction.
Without calibration, “pick where the camera saw it” becomes “miss the part cleanly and confidently.”
Example 3: Robot tool center point setup
A robot arm may be mechanically correct, but the actual tool tip is rarely located exactly where the model assumes. If the TCP is wrong, every move near the product is biased.
That kind of error is dangerous because motion appears smooth and repeatable. It is just repeatably wrong.
Why even precise machines still need it
A common beginner mistake is to think calibration exists only because mechanics are bad.
That is not true.
Calibration and alignment exist because:
- precision is finite
- assembly has tolerance
- replaceable components change geometry
- sensors and optics do not inherently share one coordinate system
- process accuracy is often tighter than assembly tolerance
- the machine changes over time
Experienced engineers assume geometry is a managed software truth, not a permanent physical fact.
PART 2 — CALIBRATION VS ALIGNMENT VS HOMING
These concepts are often mixed together by new engineers and sometimes even by operators. That creates fragile software, bad diagnostics, and wrong expectations.
Calibration
Calibration establishes or updates a trusted relationship between the machine’s physical world and the software’s model.
Typical examples:
- camera-to-stage transform
- tool offset
- focus reference position
- sensor threshold baseline
- pixel-to-world scale
Calibration usually produces persistent data that remains valid until drift, maintenance, or replacement invalidates it.
It solves this problem:
“How is this device/system actually related to the machine right now?”
Calibration is usually not part of every cycle. It is a controlled procedure.
Alignment
Alignment is the act of measuring the current product/workpiece position or orientation and computing the correction needed for this run or this part.
Typical examples:
- find wafer notch or fiducials
- detect part origin
- compute rotation correction
- shift process coordinates before execution
It solves this problem:
“Where is this particular product actually sitting right now relative to the machine’s expected frame?”
Alignment is often runtime or pre-process.
Calibration makes the machine know itself. Alignment makes the machine know the current part.
Homing / Referencing
Homing establishes a known axis reference so motion control has a valid positional basis.
Typical examples:
- move axis to home sensor
- latch encoder index
- establish machine zero/reference
It solves this problem:
“Where is the axis in its own motion coordinate system?”
Homing is about axis reference validity. It does not tell you where the wafer is, where the camera is, or whether the tool offset is correct.
A machine can be perfectly homed and still badly misaligned.
Recipe Positions
Recipe positions are nominal intended coordinates for process steps.
Examples:
- inspect site A
- dispense at position B
- place component at C
- autofocus over point D
They solve this problem:
“Where should the machine act, assuming the coordinate model is valid?”
Recipe data is not calibration data. It should not silently absorb calibration mistakes.
Runtime Correction / Compensation
This is the active application of computed offsets or transforms during execution.
Examples:
- apply alignment delta to all target points
- compensate tool center offset
- use corrected focus Z
- map camera detection into stage coordinates
It solves this problem:
“Given the current calibration and alignment state, what corrected command should be sent now?”
Why teams confuse these
Because all of them somehow “change where the machine goes.”
But they are not the same kind of truth:
- Homing → axis reference truth
- Calibration → machine geometry truth
- Alignment → current workpiece truth
- Recipe → intended process truth
- Runtime correction → execution truth after applying the others
When teams blur these together, bad things happen:
- operators think re-home fixes a camera offset
- engineers store alignment data in recipe fields
- service teams patch a bad calibration with manual recipe shifts
- software mixes temporary correction with long-term machine model
- logs become useless because nobody knows which frame a value belonged to
Strong engineers keep these concepts explicitly separate.
PART 3 — COORDINATE CORRECTION, OFFSETS & TRANSFORMS
At a practical level, calibration/alignment software is about managing multiple coordinate systems without lying to itself.
Common coordinate systems
1. Machine coordinates
The motion system’s base coordinate frame.
This is where the controller understands position, often from encoders after homing.
Example:
- stage X = 120.345 mm
- stage Y = 88.210 mm
This is not automatically the same as product coordinates.
2. Work coordinates
Coordinates relative to the product or process definition.
Examples:
- wafer center
- die map origin
- part datum
- fixture origin
Recipes are usually defined here.
3. Camera / image coordinates
Coordinates in the camera/image frame.
Examples:
- pixel location
- image center
- detected feature position
- rotation in image space
Vision results start here, but motion does not execute here.
4. Tool coordinates
Coordinates relative to the active tool or end effector.
Examples:
- nozzle center
- laser spot
- probe tip
- dispensing needle
- TCP
The machine may move one physical body, but the process acts at the tool point.
Offsets
An offset is the simplest correction: a positional difference between expected and actual.
Examples:
- tool X/Y offset from spindle center
- focus Z offset
- wafer center offset after alignment
- camera center shift after recalibration
Offsets are common because many physical problems first show up as “move by this amount.”
But experienced engineers know that not all correction is just shift. Some problems also include:
- rotation
- scale
- skew
- nonlinearity
So offsets are necessary, but not always sufficient.
Transforms
A transform is the software representation of how one coordinate frame maps into another.
In practical machine software terms, it answers:
- how camera coordinates become machine coordinates
- how part coordinates become stage targets
- how tool center becomes commanded axis position
You do not need matrix derivation to understand the software meaning:
A transform is a contract that says:
“If a point is known in frame A, here is how to interpret it in frame B.”
That contract may include:
- translation
- rotation
- scale
- sometimes more complex correction
Why corrected position is not nominal position
Because the machine does not process an abstract recipe. It processes a real part in a real machine state.
So a corrected position may be:
- nominal recipe point
- plus active alignment shift
- plus rotation correction
- plus tool offset
- plus calibration mapping between frames
That is why mature machine software distinguishes between:
- nominal target
- aligned target
- machine command position
- measured actual position
If those collapse into one undocumented number, debugging becomes miserable.
ASCII coordinate / transform diagram
+-------------------+ Transform T_wc +-------------------+
| Work Coordinate | ---------------------------> | Machine Coordinate|
| (wafer / part) | | (stage / axes) |
| Origin: product | | Origin: machine |
+-------------------+ +-------------------+
^
| T_cw
|
+-------------------+ Transform T_cm +-------------------+
| Camera Coordinate | ---------------------------> | Tool Coordinate |
| (pixels / image) | | (tip / nozzle) |
| Origin: image ctr | | Origin: tool TCP |
+-------------------+ +-------------------+What this diagram means
The machine is not living in one coordinate system.
It is constantly converting between:
- what the recipe means in work coordinates
- what the camera sees in image coordinates
- what the motion controller can execute in machine coordinates
- where the actual process point is in tool coordinates
Calibration defines trusted transforms between these frames. Alignment updates the current work-to-machine relationship for the current part.
PART 4 — CALIBRATION FLOWS
Calibration flows are controlled procedures that generate or validate correction data.
The key architectural point is this:
Calibration is not just a UI screen or a service action. It is a machine workflow that measures something physical, computes correction data, validates it, stores it, and activates it under control.
1. Axis-to-camera calibration
What is being calibrated
The relationship between stage movement and camera observation.
How the machine performs it
A known target is moved or observed at multiple positions. The camera detects the feature, and software correlates image movement with stage movement.
What data is produced
Typically:
- camera center offset relative to stage
- camera orientation relative to axis frame
- scale or pixel-to-motion mapping
- sometimes distortion model, though that goes deeper than we need here
How software stores and applies it
The result should be stored as explicit calibration data with:
- calibration type
- machine/subsystem identity
- timestamp
- operator/service identity
- version
- validity status
- activation state
Then motion/vision code uses that transform when converting detections into stage positions.
2. Pixel-to-world calibration
What is being calibrated
How image measurements correspond to physical distance in machine space.
How the machine performs it
It observes a known target or known movement and establishes how many physical units correspond to image displacement.
What data is produced
- scale factor
- orientation relationship
- possibly local correction values
How software stores and applies it
It becomes part of the camera calibration model. Vision output should not directly command motion until converted through this model.
3. Tool offset calibration
What is being calibrated
The actual process point of the tool relative to the machine reference or holder reference.
Examples:
- nozzle center
- probe tip
- laser point
- dispenser needle
How the machine performs it
The tool is measured against a reference artifact, sensor, camera, or taught datum.
What data is produced
- X/Y/Z offset
- sometimes rotation/orientation correction
- sometimes tool ID association
How software stores and applies it
It should be tied to:
- tool identity
- installation event
- machine configuration
- effective-from time
A common failure is letting tool offsets live in an operator note or hidden field.
4. Focus/reference calibration
What is being calibrated
The reference for focus or height-related process action.
How the machine performs it
The system finds a known surface or focus reference condition and records the corresponding Z or focus mechanism value.
What data is produced
- reference focus position
- offset relative to nominal
- acceptable tolerance band
How software stores and applies it
Used later in autofocus or height-sensitive routines as baseline truth.
5. Sensor threshold/reference calibration
What is being calibrated
The boundary between valid and invalid sensor interpretation.
Examples:
- vacuum sensor baseline
- height sensor reference
- edge detection threshold baseline
How the machine performs it
Measure known-good reference condition, sometimes compare to known-bad/no-signal condition, and set calibrated threshold/reference.
What data is produced
- baseline value
- threshold
- tolerance band
- environmental condition metadata if needed
How software stores and applies it
Sensor logic should refer to calibrated reference data, not hardcoded guesses.
ASCII sequence diagram — example calibration flow
Here is a practical axis-to-camera calibration flow:
Operator/Service UI Calibration Manager Motion System Vision System Calibration Store
| | | | |
| Start calibration | | | |
|---------------------->| | | |
| | Move to ref points | | |
| |-------------------->| | |
| |<--------------------| Motion complete | |
| | Trigger capture | | |
| |--------------------------------------->| |
| |<---------------------------------------| Feature positions |
| | Repeat for samples | | |
| | Compute transform | | |
| | Validate tolerances | | |
| | Save candidate ------------------------------------------------>|
| |<----------------------------------------------------------------|
| Review/activate | | | |
|---------------------->| | | |
| | Mark active ---------------------------------------------------->|
| |<----------------------------------------------------------------|What this diagram means
A real calibration flow is not just “calculate an offset.”
It includes:
- controlled motion
- measurement acquisition
- computation
- validation
- persistence
- activation
That is why calibration deserves first-class architectural treatment.
PART 5 — ALIGNMENT FLOWS
Alignment is usually closer to runtime production behavior.
It answers: Where is this specific wafer/part right now, and how should I correct the upcoming process?
1. Fiducial-based alignment
How measurement is taken
The machine moves to expected fiducial locations, captures image/sensor data, and detects actual fiducial positions.
How offsets are computed conceptually
Compare expected fiducial positions to detected positions.
That gives:
- translation shift
- often rotation
- sometimes scale/skew if needed
How coordinates are corrected
The machine updates the work-to-machine mapping for this run, so recipe targets are corrected before execution.
2. Wafer alignment
How measurement is taken
The machine may find wafer center, notch, flat, or alignment marks using camera or dedicated sensors.
How offsets are computed conceptually
Compute where the wafer is actually centered and how it is rotated relative to expected wafer frame.
How motion/process coordinates are corrected
The die map or inspection path is rotated/shifted into the actual wafer pose.
This is one of the clearest examples of why “recipe coordinates” are not enough.
3. Part origin finding
How measurement is taken
Find datum edges, holes, corners, fiducials, or known features.
How offsets are computed conceptually
Determine actual part origin relative to machine expected origin.
How correction is applied
Shift process positions so dispensing, probing, imaging, or placement occurs relative to actual part location.
4. Rotational correction
How measurement is taken
Usually detect two or more reference features or one feature with known orientation.
How offsets are computed conceptually
Translation alone is not enough. The system estimates angular mismatch between expected and actual part pose.
How correction is applied
All planned process points are rotated into corrected frame before execution.
This is a classic place where weak software shows up. Teams often patch translation but forget rotation.
5. Runtime re-alignment before process execution
In high-accuracy systems, the machine may perform a quick realignment just before a sensitive step.
Why?
Because even if the part was aligned earlier:
- it may have shifted during handling
- chuck/vacuum conditions may have changed
- thermal settling may have changed geometry
- previous operations may have introduced slight repositioning error
Strong systems distinguish between:
- initial alignment
- alignment validity
- re-alignment trigger conditions
PART 6 — DRIFT & RE-CALIBRATION
Calibration is never “done once forever.”
That belief causes some of the ugliest production failures because the machine keeps working just well enough that drift hides until yield or quality drops.
1. Thermal drift
What it looks like in production
The machine is more accurate in the morning than after several hours of operation. Errors correlate with warm-up, illumination time, spindle usage, or environment changes.
How it affects quality/positioning
- image-to-stage relationship shifts
- focus plane changes
- precision placement degrades
- measurements drift over time
How engineers handle it
- warm-up requirements
- thermal stabilization rules
- periodic revalidation
- environmental monitoring
- temperature-aware recalibration triggers
2. Mechanical wear
What it looks like
Repeatability worsens slowly. Backlash, compliance, looseness, or mounting play shows up as inconsistent correction.
How it affects quality
- calibration no longer stays valid
- alignment residuals worsen
- different directions yield different results
- same nominal position behaves differently depending on approach path
How engineers handle it
- trend calibration residuals
- compare repeatability across cycles
- define maintenance thresholds
- avoid assuming software can “correct away” mechanical degradation forever
3. Camera mounting shift
What it looks like
After service or vibration event, camera-based positioning is biased even though motion appears normal.
Effect
Vision sees correctly in its own frame, but mapping to machine coordinates is wrong.
Handling
- mount integrity checks
- post-maintenance recalibration requirement
- explicit invalidation of related calibration records
4. Tooling replacement
What it looks like
A new nozzle, probe, or tool is installed and process points are all slightly off.
Effect
Everything is shifted even though axes and camera are fine.
Handling
- tool-specific calibration
- activation blocked until tool calibration completed
- tool identity linked to offset data
5. Maintenance changes
What it looks like
A subsystem was touched during service, and suddenly previously valid alignment/calibration assumptions are no longer trustworthy.
Effect
The dangerous part is that the machine may still pass simple checks but fail production accuracy.
Handling
Experienced teams define calibration invalidation rules:
- if this component is replaced
- if this mount is loosened
- if this sensor is reinstalled
- if this controller parameter changes
then related calibration must be revalidated before release.
6. Sensor aging
What it looks like
Threshold-based detection gradually shifts. Signals become noisier or baseline changes.
Effect
Reference finding becomes less stable. Alignment may “succeed” with poor-quality measurement.
Handling
- baseline trend monitoring
- reference checks
- tolerance drift alarms
- scheduled recalibration
PART 7 — REAL-WORLD FAILURE SCENARIOS
1. Wrong calibration data loaded
What it looks like in production
The machine runs, alignment may even appear normal, but targeting error is consistent. Often happens after restore, software update, machine clone, or product line mix-up.
Why it is difficult
Because the values may be internally self-consistent. Nothing crashes. The system is just using valid-looking data for the wrong hardware state.
How experienced engineers handle it
- machine-specific calibration identity
- hardware/configuration compatibility checks
- activation audit trail
- visible “active calibration set” display
- compare against expected signatures or validation runs
2. Coordinate frame mismatch
What it looks like
A point detected by vision is transformed incorrectly: mirrored, rotated wrong, or shifted in the wrong frame.
Why difficult
Everything individually looks reasonable:
- camera found the mark
- stage moved
- no alarm
- final target still missed
This is one of the most common “software looks correct locally, system is wrong globally” problems.
How engineers handle it
- explicit frame naming in code and logs
- never pass naked X/Y pairs without frame context
- diagnostic overlays showing expected vs detected vs corrected points
- test artifacts that verify full transform chain
3. Stale offsets after maintenance
What it looks like
Machine passed restart and homing, but process accuracy degraded right after service intervention.
Why difficult
Operators often assume “it was serviced, so it should be better.” Teams may overlook that offsets were invalidated.
How engineers handle it
- maintenance workflow linked to calibration invalidation
- lockout until recalibration/verification done
- service checklist with dependent calibration items
4. Alignment succeeds but target is still missed
What it looks like
UI says alignment successful, yet process action still lands off target.
Why difficult
This means the alignment subflow worked according to its local criteria, but the broader correction pipeline is broken.
Possible causes:
- alignment output not applied
- wrong transform chain
- wrong tool offset
- stale active correction
- measurement quality not strong enough
How engineers handle it
They inspect the whole pipeline:
- raw measurement
- computed correction
- activated correction
- final commanded position
- measured execution result
Strong teams never stop at “alignment success = system success.”
5. Operator skips required re-calibration
What it looks like
Machine runs after tool change or service, but quality drift begins immediately.
Why difficult
Sometimes the machine technically allows operation. The missing step is procedural, not mechanical.
How engineers handle it
- block critical operation when calibration state invalid
- show explicit dependency warnings
- design workflows so required calibration cannot be bypassed casually
6. Software silently mixes nominal and corrected positions
What it looks like
Some steps use corrected coordinates, others use recipe nominal coordinates. Results are inconsistent and confusing.
Why difficult
This kind of bug often comes from code growth over time. One path applies correction in the motion service; another path assumes caller already corrected it.
How engineers handle it
- one authoritative correction pipeline
- explicit types/models for nominal vs corrected targets
- code reviews focused on coordinate ownership
- logs that show both nominal and corrected value
PART 8 — SOFTWARE DESIGN IMPLICATIONS
Calibration/alignment should be first-class architectural concepts, not scattered implementation details.
That is because they are not minor arithmetic helpers. They define whether machine commands correspond to physical reality.
Why they must be first-class
Because the software must answer questions like:
- Which coordinate frame is this value in?
- Which calibration set is active?
- Is this transform valid for the installed tool/camera?
- Was alignment performed for this run?
- Is correction required, optional, or prohibited?
- Was this value nominal, aligned, or final commanded?
If architecture cannot answer those questions clearly, the machine will accumulate hidden geometric truth in random places.
Why offsets/transforms should not be hidden in random code
Bad systems often have “just add this offset” logic in:
- UI handlers
- motion wrappers
- recipe import code
- vendor SDK adapters
- operator maintenance screens
- vision script snippets
That becomes impossible to reason about.
It also makes failures asymmetric:
- one feature works
- another feature misses
- one station applies correction twice
- another not at all
Important architectural principles
1. Explicit coordinate models
Do not pass anonymous numbers if the frame matters.
Bad:
MoveTo(x, y)Better:
MoveTo(machinePosition)Or:
Transform(workPoint) -> machineTargetThe goal is to make coordinate intent visible in code.
2. Calibration data ownership
Every calibration item should have clear ownership:
- who computes it
- who validates it
- who stores it
- who activates it
- who consumes it
Do not let five components interpret the same geometric truth differently.
3. Versioning and traceability
Calibration and alignment are operational data with quality impact.
You want:
- record history
- timestamps
- operator/service identity
- machine/tool identity
- software version if relevant
- reason for invalidation
- validation result
- active/inactive state
This is critical for both debugging and production accountability.
4. Validation before activation
New calibration data should often be a candidate before it becomes active.
Why?
Because measured data may be:
- incomplete
- noisy
- computed from wrong reference
- outside expected tolerance
- accidentally captured on wrong setup
Strong systems support:
- compute
- review/check
- validate
- activate
not just “save and immediately trust.”
5. Clear distinction between nominal and corrected value
This one is extremely important.
The software should make it easy to see:
- recipe nominal point
- alignment delta
- calibration transform result
- final commanded point
- actual measured point
When these are collapsed together, diagnostics become guesswork.
Good vs bad approaches
Bad
- magic offsets in code
- operator-entered manual shifts hidden in config text
- one subsystem “knows” camera correction implicitly
- recipe values permanently patched to compensate machine error
- no audit trail for calibration changes
- no clear active/inactive calibration state
- correction logic duplicated in multiple places
Good
- explicit coordinate/frame models
- central calibration manager or correction pipeline
- traceable calibration records
- validation and controlled activation
- transform usage visible in code and diagnostics
- machine state aware of calibration validity
- downstream consumers receive already well-defined corrected targets
ASCII component diagram
+------------------+ +----------------------+ +------------------+
| Operator UI / | -----> | Calibration Manager | -----> | Transform Model |
| Service Tool | | | | / Correction Core|
+------------------+ +----------------------+ +------------------+
| |
| |
v v
+----------------------+ +------------------+
| Calibration Store | | Motion / Vision |
| version + audit | | subsystems |
+----------------------+ +------------------+What this diagram means
A healthy architecture usually separates:
- UI / service workflows that initiate calibration
- a calibration manager that owns orchestration and validity
- a transform/correction model that applies trusted geometric rules
- a calibration store that handles persistence, versioning, traceability
- motion/vision subsystems that consume well-defined correction data
That separation prevents hidden coordinate logic from spreading everywhere.
PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS
How to explain calibration and alignment clearly
A strong simple explanation:
Calibration establishes trusted geometric relationships inside the machine. Alignment measures the actual pose of the current product and computes run-time correction. Homing only establishes axis reference. Good machine software keeps those separate and applies correction through an explicit, traceable pipeline.
That answer is clean, practical, and shows you understand the difference between machine truth and runtime part truth.
Why offsets and transforms matter in machine software
Because machine software does not act in one coordinate world.
It must continuously bridge:
- motion controller coordinates
- product/process coordinates
- camera/image coordinates
- tool/process coordinates
Offsets and transforms are the software structures that preserve coordinate integrity across those worlds.
Without them, the machine can move correctly in the wrong frame.
Common mistakes software engineers make when entering machine software
The biggest ones are:
- Thinking homing solves accuracy
- Treating recipe positions as directly executable truth
- Hiding offsets in ad hoc code
- Passing coordinate values without frame identity
- Assuming calibration is permanent
- Believing “alignment success” means end-to-end targeting success
- Mixing nominal and corrected positions in the same variable path
These are classic domain transition mistakes.
What strong engineers understand about coordinate integrity and drift
Strong engineers understand that:
- coordinate integrity is a system property, not a local function
- calibration data has lifecycle, ownership, and validity
- correction must be explicit and inspectable
- the machine changes over time
- production accuracy depends as much on disciplined software truth as on mechanical precision
They do not treat calibration as a one-time service screen. They treat it as part of machine architecture.
Final mental model
If you want one compact mental model, use this:
- Homing tells the machine where its axes are.
- Calibration tells the machine how its subsystems relate to each other.
- Alignment tells the machine where the current product actually is.
- Correction turns that truth into executable motion/process commands.
- Re-calibration exists because physical reality drifts.
That is the software perspective on calibration and alignment.
And in real industrial software, the mature question is never just:
“Can the machine move there?”
It is:
“Can the machine prove that ‘there’ is the correct physical place, in the correct frame, with currently valid correction data?”
That is the difference between demo-grade machine software and production-grade machine software.
This topic is explicitly part of Domain 1’s source of truth under Calibration & Alignment, focused on coordinate correction, offsets and transforms, alignment flows, drift, and re-calibration.
If you want, I can turn this into the same bilingual English-Vietnamese format you used for the earlier Domain 1 topics.