PacketStation/docs/POLICY.md

Packet Station policy

Who may do what to a packet, and when. This file is written from the code in server/packetstation/policy/. When they disagree, the code is the rule and this file is out of date.

Purpose

The policy is a Python port of the old guard.js. It runs only on the server. Every packet write calls policy.check() inside the write transaction, under the packet row lock. Every packet read returns can, blocked and holder from the same rules, so the screens only show what the server will accept. The Q.C. folder and ITP writes belong to a project or a unit, not to a packet; they call policy.check_scoped() under their own row lock (see "Scoped checks").

The package is pure functions with no I/O:

• actions.py: the Action enum, the Who predicates, the Rule record and the RULES table.
• principal.py: Principal, PacketState, principal_from_roles().
• custody.py: holds(), works_on(), holder_name() and the Who predicates.
• preconditions.py: the named preconditions and their messages.
• engine.py: check(), check_scoped(), evaluate(), can() and Decision.

Roles

Every role comes from an AD group (see docs/SECURITY.md). The role strings are admin, clerical, clerical_supervisor, warehouse, warehouse_supervisor, qc, qc_supervisor, pm and shop:<code>:<worker|lead|supervisor>. A person's roles are the union of their groups.

principal_from_roles(user_id, roles, station_limits=(), session_kind="password") builds the policy's Principal:

Field	Meaning
admin	In PS-Admins. Admin is not membership. It is the bypass rule below.
support	The codes among CL, WH and Q.C. the person belongs to, at any level. A supervisor role implies membership.
support_sup	The codes among CL, WH and Q.C. where the person is Supervisor.
shop	Shop department code to level: 1 worker, 2 lead, 3 supervisor. The highest level wins.
station_limits	Station ids a worker is limited to. Empty means any station.
pm	Project Management. PM can read every packet and change nothing.
session_kind	password or pin.
system	visual-feed for the worker. Never set from a session.

A role string that does not parse is ignored.

Custody

Only whoever holds the packet may change it. Everyone else can open it and follow it.

Status	Holder
draft	Clerical
warehouse	Warehouse
ready, review	Lead or supervisor of the packet's department
assigned, in_progress	Lead or supervisor of the department, or a worker who works on it
qc	Q.C.
complete	Clerical (data book)
filed	Nobody

works_on(principal, state): a member of the packet's department. Leads and supervisors always pass. A worker passes when they have no station limits, or the limits hold the packet's station. START and SUBMIT also need the assigned welder for a worker (see the tightenings).

holder_name(state, dept_name, station_name) gives the text for messages: "Clerical", "Warehouse", "Q.C.", "Clerical (data book)", "the data book (filed)", else the department name, plus " · " while the packet is at a station.

Statuses in workflow order: draft, warehouse, ready, assigned, in_progress, review, qc, complete, filed. SHOP is ready, assigned, in_progress and review. ACTIVE is assigned and in_progress.

Who

Who	Passes when
CL, WH, QC	A member of that support department, any level
CL_SUP, WH_SUP, QC_SUP	Supervisor of that support department
CL_OR_QC	A member of Clerical or Q.C.
HOLDER	Holds the packet (custody above)
DEPT_LEAD	Lead or supervisor in the packet's department
DEPT_SUP	Supervisor in the packet's department
WORKS_ON	Lead or above in the department, or a worker in the department who is the assigned welder and whose station limits allow the station
CO_VERIFIER	Supervisor of the department named in the request: a shop Supervisor for a shop code, WH or Q.C. Supervisor for WH or QC. Clerical never verifies.
ADMIN	In PS-Admins
SYSTEM	The worker (system is set)

Rule table

from is the set of statuses the action starts from. "any" means any status, with the filed lock applied separately. co hold means an open change order holds the step.

Action	Who	From	To	Dept	CO hold	Preconditions	Signature	Reason
send_to_warehouse	CL	draft	warehouse	no		heat_map_answered, drawing_attached
release_to_shop	CL	draft	ready	allowed		heat_map_answered, drawing_attached, target_dept_given
send_draft_to_qc	CL	draft	qc	no		heat_map_answered, drawing_attached
wh_send_back	WH	warehouse	draft	no		reason_given		yes
return_to_clerical	DEPT_LEAD	ready, only when wh_skipped	draft	no		reason_given		yes
wh_release	WH	warehouse	ready	no	yes	bom_all_pulled_or_short, heats_recorded
send_back_to_warehouse	DEPT_LEAD	ready	warehouse	no		reason_given		yes
assign	DEPT_LEAD	ready	assigned	no		welder_set
unassign	DEPT_LEAD	assigned	ready	no
pull_back	DEPT_LEAD	in_progress	ready	no
start	WORKS_ON	assigned	in_progress	no
submit	WORKS_ON	assigned, in_progress	review	no	yes	checklist_complete, welds_recorded, filler_set	Submit work to the supervisor
return_to_station	DEPT_SUP	review	assigned	no		reason_given		yes
send_to_qc	DEPT_SUP	review	qc	no	yes	qc_book_spool_location	Send to Q.C.
route_from_review	DEPT_SUP	review	ready	required	yes	target_dept_given	Route to another department
qc_reject	QC	qc	review	no		reason_given	Q.C. reject	yes
qc_accept	QC	qc	complete	no	yes	qc_missing_empty, route_given	Q.C. accept
qc_accept_and_route	QC	qc	ready	required	yes	qc_missing_empty, target_dept_given	Q.C. accept and route
file	CL	complete	filed	no	yes	vclosed_if_databook	File in the data book
admin_reopen	ADMIN	filed (filed_ok)	complete	no		reason_given	Reopen a filed packet	yes
edit_header	CL	draft
edit_drawing_ref	CL	any
edit_dept	CL	draft
move_unit	CL	any
edit_wos	CL	draft
edit_bom	HOLDER	draft, warehouse, SHOP
wh_receive_short	WH	any				short_open
edit_heats	HOLDER	warehouse, SHOP
edit_heat_table	HOLDER	warehouse, SHOP
edit_welds	HOLDER	SHOP
edit_checklist	HOLDER	SHOP
edit_stage_fields	HOLDER	SHOP
clock	HOLDER	SHOP
edit_qc	QC	qc
set_wh_stage	WH	warehouse
edit_document_set	CL	any					Attach a drawing by hand (attach only)
doc_add	CL_OR_QC	any
doc_remove	CL_OR_QC	any
rev_approve	CL_SUP	draft				reason_given	Approve the M-Files revision	yes
set_vclosed	CL	complete, only when routed_to is databook
set_databook_at	CL_OR_QC	any (filed_ok)
remove	CL	draft				reason_given		yes
co_issue	CL	any					Issue a change order
co_approve	CL	any					Approve a change order
co_reject	CL	any				reason_given	Reject a change order	yes
co_hold_toggle	CL	any
co_verify	CO_VERIFIER	any					Verify a change order for the department
qc_doc_add	CL_OR_QC	no packet (scoped)
itp_start	QC	no packet (scoped)
itp_line_sign	QC	no packet (scoped)
itp_line_unsign	QC	no packet (scoped)
itp_edit_line	QC	no packet (scoped)
itp_block_sign	QC	no packet (scoped)					Sign an ITP block
itp_block_unsign	QC	no packet (scoped)
itp_sign_off	QC	no packet (scoped)					Sign off the ITP
itp_reopen	QC_SUP (Admin through the bypass)	no packet (scoped)				reason_given		yes
vis_update_draft	SYSTEM	draft
vis_retire_draft	SYSTEM	draft
vis_open_co	SYSTEM	any but draft and filed
vis_auto_release	SYSTEM	draft	warehouse			heat_map_answered, drawing_attached

A holder of the packet who is not in the warehouse receives a short through edit_bom (see "Receive by custody").

The vis_* actions are system only. People can never do them, and the worker can do nothing else.

The Q.C. folder and ITP actions ("no packet (scoped)") belong to a project or a unit, not to a packet. They are checked with check_scoped() (see "Scoped checks"), never with the packet status, custody or the filed lock.

qc_reject takes an NCR number in place of the reason text (see "Q.C. (phase 6)", "Reject").

Preconditions

Each precondition is a named predicate over the packet state and the request input. They are never bypassed, Admin included. The first one that fails gives the message.

Name	Passes when	Message
heat_map_answered	heat_map is yes or no	Say whether this packet needs a heat map.
drawing_attached	a drawing is attached	Attach the drawing first.
bom_all_pulled_or_short	every line not marked n/a is pulled or has an open short	Pull every material line or mark it short first.
heats_recorded	no line needs a heat: every line that is not N/A, not a sub-assembly, is pulled and issued pieces has a heat	Scan or type the heat number of every pulled line first. Use N/A for a part with no traceability.
short_open	at least one BOM line has an open short (the old whCanReceive)	No part is short on this packet.
welder_set (input)	the request gives station_id and welder_id	Pick a station and a welder.
checklist_complete	every key of the department checklist is done	Finish the checklist first.
welds_recorded	at least one weld in the packet's current department, in a weld department	Record at least one weld first.
filler_set	filler metal entered, in a weld department	Enter the filler metal first.
qc_book_spool_location (input)	book and spool confirmed and a location given	Confirm the book and the spool, and give the location.
qc_missing_empty	the Q.C. record has nothing missing	Q.C. still needs: (the list).
reason_given (input)	a reason of at least 8 characters after cleaning	Give a reason of at least 8 characters.
vclosed_if_databook	routed to Shipping, or closed in VISUAL	Close the job in VISUAL first.
co_staged_if_dwg_change (input)	no drawing change, or the new drawing is staged (phase 3)	Stage the new drawing for the change order first.
route_given (input)	routed_to is databook or shipping	Choose Data Book or Shipping.
target_dept_given (input)	a shop department different from the packet's; from a draft any shop department	Choose a department. / Choose a different department.

"(input)" marks a precondition that reads request input, not packet state. can() skips those.

Order of checks

check(principal, state, action, *, extra={}, it_reason=None) -> Decision runs these in this order and stops at the first failure:

1. Removed. A removed packet refuses everything, Admin included. Code removed.
2. Status. The status must be in the rule's from set. RETURN_TO_CLERICAL also needs wh_skipped. SET_VCLOSED also needs routed_to databook. An unknown status fails here too. Code wrong_status.
3. Change-order hold. A held action refuses while an approved change order waits for verification, or a pending one is on hold. Admin included. Code co_hold, with the hold text.
4. System. A system-only action refuses every person (system_only). The system principal passes only system-only actions (forbidden).
5. Admin bypass. An admin who is not allowed by the rule's Who passes who and custody when an IT reason of at least 8 characters is given. Without one the code is it_reason_required. SET_DATABOOK_AT needs no reason. The decision is marked admin_bypass, and the write marks the log row as an IT edit.
6. Filed lock. A filed packet refuses everything except SET_DATABOOK_AT and ADMIN_REOPEN, Admin included. Code filed: "This packet is filed and locked. IT can reopen it if a correction is needed."
7. Who and custody. Code forbidden. For a step: "Your access doesn't allow this step." For an edit: "Your access doesn't allow changing (what) on this packet. It's with (holder) right now." PM fails here for everything.
8. Preconditions, in rule order, never bypassed. Code precondition with the message, or reason_required when the missing piece is the rule's reason, so the screen can ask for one.

Decision carries ok, code, why, admin_bypass, signature (the meaning text when the rule needs one) and, in read mode only, reasons.

The packet API answers 403 with the code for most failures, and 400 for it_reason_required and reason_required.

Scoped checks

check_scoped(principal, action, *, extra=None, it_reason=None) -> Decision runs the same steps as check() without a packet, for the actions that belong to a project or a unit (the Q.C. folder and the ITP):

1. System. A system principal fails (forbidden). A system-only action fails every person (system_only).
2. Admin bypass. An admin not allowed by the rule's Who passes with an IT reason of at least 8 characters, else it_reason_required. The decision is marked admin_bypass.
3. Who. Code forbidden, "Your access doesn't allow this."
4. Preconditions, the input ones in rule order. reason_given fails as reason_required.

There is no removed, status, change-order hold, filed lock or custody step: there is no packet and no holder. The ITP and Q.C. folder writes call it inside their own transaction, under the itps row lock or the lock on the Q.C. document being replaced. They never take a packet row lock, because they change no packet and must not wait on, or block, the packets of the unit.

Signatures

These actions need a signature: submit, send_to_qc, route_from_review, qc_reject, qc_accept, qc_accept_and_route, file, admin_reopen, edit_document_set (attach only), rev_approve, co_issue, co_approve, co_reject, co_verify, itp_block_sign and itp_sign_off. The rule's signature text is the meaning that is signed.

The request carries sign: {factor, secret}. The write pipeline calls the phase 1 helper packetstation.auth.signatures.sign() inside the same transaction, after the policy passes. It checks the PIN or domain password against the session's own user. A PIN works in any session. It logs the attempt and applies the five-strike PIN disable and the three-strike session end. It writes an append-only signatures row with the user, session, account, display name, session kind, factor, action, meaning, packet, subject and a sha256 over the canonical JSON of what was signed (the action, the packet id, the expected state and the request fields). The packet_transitions and packet_log rows point at it.

Concurrency

• Workflow steps are compare-and-set on expect: {status, dept} under the packet row lock (SELECT ... FOR UPDATE). When the packet moved on, the answer is 409 stale_step "Someone else already took this step." with the current status, department and version. There is no packet version check on a step, so a weld edit never blocks a send. Side effects run in the same transaction.
• Keyed child rows (BOM lines, Q.C. inspections, stage fields, welds, heat tags) take If-Match: <row_version>. A mismatch is 409 row_conflict with the current row.
• Numbers for welds, heat tags, pages and change orders come from counters on the packet row under the row lock, so concurrent adds never collide.
• Header scalars use field-level compare-and-set: the body sends set and base. A key whose base differs from the current value is 409 field_conflict with the current value. A key with no base is written as is.
• Work orders are a draft-only full replace with If-Match on the packet version.
• Shorts and change-order actions are state compare-and-set. Checklist keys are written one key at a time. The heat table position is an idempotent upsert. A change-order verification is an insert, so a second one is "already verified".
• ITP lines are approved under the itps row lock, with a state check and an optional If-Match: <row_version>. ITP header fields use the same set and base field compare-and-set as packet headers.
• Append-only tables never conflict: packet_transitions, packet_log, qc_history, short_receipts, project_renumbers, itp_rejects, itp_log and co_verifications. Triggers refuse UPDATE, DELETE and TRUNCATE, and the app role has no grant for them.

Reads: can, blocked and holder

Every packet read returns:

• can: the actions that pass now. Input-only preconditions are skipped, because they are what the user gives with the step.
• blocked: the actions that pass who and custody but fail a state precondition or the change-order hold, with every reason. The screen shows the control disabled with the reason.
• holder: holder_name() for the packet.

can(principal, state, assume_it_reason=True) -> (list[Action], dict[Action, list[str]]). For an admin the IT reason is assumed, so the list shows what the admin may do once they give one. evaluate(principal, state, action) returns the read-mode decision with admin_bypass set, so the screen knows to ask for the reason. System-only actions are never listed. CO_VERIFY needs a department in the request, so it is not listed; the change order list says which departments the person can verify.

Warehouse (phase 4)

Stages

The warehouse stage is packet_wh, separate from the packet status. SET_WH_STAGE (WH, status warehouse) moves it, compare-and-set on expect_stage (409 stale_step when it moved on).

From	To
incoming	pulling, hold
pulling	pulled, hold
hold	pulling
pulled	pulling

A move to the same stage, or one not in the table, is 409 wh_transition. A packet with no packet_wh row is at incoming. The first Pulled tick on a line while the stage is incoming or on hold starts pulling by itself (auto true).

Hold reasons

A closed set, checked on the server:

• Waiting on material (not in stock)
• Waiting on purchasing / PO
• Question for engineering or clerical
• Drawing / BOM problem
• Other

Any other text is 400 invalid_reason "Pick one of the hold reasons." "Other" needs a note, else 400 reason_required "Say what it's waiting on." The note is cleaned and cut to 200 characters.

Short reasons

A closed set, checked on the server:

• Not in stock
• On order
• Back-ordered
• Damaged / rejected
• Wrong part received
• Needs cutting / prep
• Other

Any other text is 400 invalid_reason "Pick one of the short reasons." A short has a quantity from 1 to the line quantity, a reason, an optional PO or requisition, an optional expected date, an optional note, and the optional heat of the pieces that were pulled (never on an N/A line). Opening, editing and clearing a short is edit_bom, so the holder decides. In practice that is the warehouse.

The release gate

WH_RELEASE checks two preconditions, in this order:

1. bom_all_pulled_or_short: every line not N/A is pulled or has an open short.
2. heats_recorded: no line needs a heat. A line needs a heat when it is not N/A, not a sub-assembly (sub is Y; its heat is on its own packet), is pulled, has issued more than 0 and has no heat.

Both are state preconditions, so blocked.wh_release lists the failing message and the screen shows Release disabled with it. Heat numbers are checked against the old pattern: letters, numbers, space . / # _ - only, up to 40 characters, starting with a letter or a number. A bad heat is 422 invalid_heat.

Receive by custody

Receiving short parts (POST .../bom/{item}/short/receipts) picks its action from the person:

• A member of the warehouse (WH in support) receives through WH_RECEIVE_SHORT, in any status but filed, while the line has an open short. The warehouse does not need to hold the packet.
• Anyone else receives through EDIT_BOM, so only the holder may: the lead or supervisor of the department that has the packet, Q.C. at Q.C., Clerical in draft.
• Everyone else is refused by the policy (403 forbidden).

The warehouse still cannot change any other field of a packet it no longer holds. EDIT_BOM stays the holder's. A receipt needs a heat unless the line is N/A, and its quantity is 1 to what is still open.

MTR files

The MTR on a line must be an asset whose type is PDF, PNG or JPEG. Anything else, or an asset that is not there, is 422 invalid_asset. Clearing the MTR is allowed.

Packet log texts

The action column of packet_log for each warehouse write. {item} is the BOM item number.

Write	action	note
Heat typed or scanned	Heat recorded · item {item}	the heat
Heat cleared	Heat cleared · item {item}
Pulled ticked	Pulled · item {item}
Pulled unticked	Pulled undone · item {item}
N/A ticked	Marked N/A · item {item}
N/A unticked	Traceable again · item {item}
Issued only	Issued qty changed · item {item}	{issued} of {qty}
Location only	Location set · item {item}	the location
Several fields	Line changed · item {item}
MTR attached	MTR attached · item {item}
MTR removed	MTR removed · item {item}
Short opened	Short recorded · item {item}	{qty} of {need} short · {reason} · {ref} · ETA {eta}, parts present only
Short edited	Short updated · item {item}	the same as recorded
Not short after all	Short cleared · item {item}
Short received	Short received · item {item}	{qty} pc · heat {heat} · {still} still short or ... · short closed, then · packet {status} (lower case) and in {station} when at a station
Stage incoming to pulling	Warehouse: Started pulling
Stage to hold	Warehouse: Put on hold	{reason} · {note}
Stage pulling to pulled	Warehouse: Marked pulled, ready for production
Stage hold to pulling	Warehouse: Pulling resumed
Stage pulled to pulling	Warehouse: Back to pulling
wh_release	Released to supervisor, or Released to supervisor with {n} short when shorts are open	{heats} heats recorded, plus · SHORT: item {item} ×{qty_open} ({reason}), ... when shorts are open
wh_send_back	Sent back to Clerical	the reason

When a Pulled tick starts pulling by itself, there is no separate stage row in the log: the line's own row gets · started pulling or · pulling resumed on its note. Every write above also writes its audit row through the write pipeline, with detail.item, wh_from and wh_to as before, and detail.qty on short writes.

Shop (phase 5)

Who takes each step

Action	Who	From	Notes
assign	Lead or supervisor of the packet's department (DEPT_LEAD)	ready	Station and welder checked at assign time (below)
unassign	DEPT_LEAD	assigned	Clears station and welder, folds the clock
pull_back	DEPT_LEAD	in_progress	Clears station and welder, folds the clock
start	Lead or supervisor of the department, or the assigned welder within their station limits (WORKS_ON)	assigned	Starts the clock
submit	WORKS_ON	assigned, in_progress	Stops the clock. Signature "Submit work to the supervisor"
return_to_station	Supervisor of the department (DEPT_SUP)	review	Reason
send_to_qc	DEPT_SUP	review	Signature "Send to Q.C.". Opens the inspection
route_from_review	DEPT_SUP	review	Signature "Route to another department". Closes the stage and opens one in the target department
send_back_to_warehouse	DEPT_LEAD	ready	Reason
return_to_clerical	DEPT_LEAD	ready, only when wh_skipped	Reason

A worker who is not the assigned welder cannot start or submit. Neither can the assigned welder when their station limits leave out the packet's station. Every step sends expect: {status, dept}, so a stale screen gets 409 stale_step "Someone else already took this step."

Assign checks

ASSIGN checks the station and the welder on the server, at assign time:

Check	Refusal
The station is an active station of the packet's department	422 invalid_station
The welder is an active user with a shop role (worker, lead or supervisor) in the packet's department	422 invalid_welder "Pick a welder in this department."
A worker with station limits (no lead or supervisor role in the department) is limited to the chosen station	422 station_limit "{name} is limited to {station names}."
A stamp in the body matches the stamp pattern	422 invalid_stamp

The stamp in the body overrides the user's welder_stamp for this assignment. Without it, the user's stamp is used. The packet and the stage row both get the station, the welder and the stamp. GET /api/departments/{code}/people gives the assign sheet its welder list, with each person's level and station limits.

The lead's review

A lead holds a packet in review (see "Custody"), but return_to_station, send_to_qc and route_from_review are the supervisor's. The server refuses them to a lead with 403 forbidden. The screen shows the lead the review read-only: "A supervisor for 03 Weld Parts reviews it and sends it on."

Preconditions on the shop steps

Step	Precondition	Passes when	Message
assign	welder_set (input)	the request gives station_id and welder_id	Pick a station and a welder.
submit	checklist_complete	every key of the department's checklist is done	Finish the checklist first.
submit	welds_recorded	at least one live weld whose dept_code is the packet's current department, in a weld department	Record at least one weld first.
submit	filler_set	filler metal entered on the open stage, in a weld department	Enter the filler metal first.
send_to_qc	qc_book_spool_location (input)	book and spool confirmed and a location given	Confirm the book and the spool, and give the location.
return_to_station, send_back_to_warehouse, return_to_clerical	reason_given (input)	a reason of at least 8 characters after cleaning	Give a reason of at least 8 characters.
route_from_review	target_dept_given (input)	a shop department different from the packet's	Choose a department. / Choose a different department.

welds_recorded counts only the current department's welds. After a route, the new department needs a weld of its own before it can submit. The welds from earlier departments are carried marks (see SCHEMA.md, "Carried marks").

Change-order hold

An open change order holds these steps: WH_RELEASE, SUBMIT, SEND_TO_QC, ROUTE_FROM_REVIEW, QC_ACCEPT, QC_ACCEPT_AND_ROUTE and FILE. It does not hold ASSIGN, START, the clock or the edits, so the shop keeps working while the departments verify. A change order is open when it is approved with departments still to verify, or pending with hold on (v_open_cos).

The hold text (the co_hold refusal and the blocked reason):

Change order	Text
Pending, with hold	CO-2: Clerical is reviewing a change from VISUAL. Held until Clerical approves or rejects it.
Approved, departments pending	Change order CO-2 must be verified first by: 03 Weld Parts, 09 Hydro.

With several open change orders, the texts are joined by a space, one sentence each. The id is CO-<co_no> everywhere.

Change-order verification

CO_VERIFY is the supervisor of the department named in the request: a shop Supervisor for a shop code, the WH or Q.C. Supervisor for WH or QC. A lead cannot verify (403 forbidden). Clerical never verifies. Each verification needs a signature ("Verify a change order for the department") and is an insert into co_verifications. A second one for the same department is 409 already_verified. A department the change order does not need is 422 invalid_dept. A verification cannot be withdrawn.

The required departments on approval are the departments the change touches, without Clerical and PM. A minor change order needs none.

The clock

CLOCK is the holder's in the shop statuses. The ops are start, pause and resume. An op in the wrong state is 409 clock_state. The server keeps the time with the database clock. No request sets the elapsed time. START starts the clock when it is not running. SUBMIT stops it. UNASSIGN and PULL_BACK fold the running time in, so the clock freezes. See SCHEMA.md, "The clock".

Marks on the drawing

Welds (EDIT_WELDS), heat tags (EDIT_HEATS) and the heat table (EDIT_HEAT_TABLE) follow the rule table: the holder in the shop statuses, and for heat tags and the heat table also the warehouse while it holds the packet. The server hands out W<n> and H<n> from the packet counters under the packet row lock.

A VOID sheet refuses marks. A new weld or heat tag on a voided page, or a move of one already there, is 422 void_page "This sheet is VOID. Mark the current sheet." The marks on a void page stay and are shown, but cannot be edited.

Heat map borrowing

A packet borrows a sibling's heat map when all of these hold (the old heatSrc):

• It has no heat map of its own: no heat table placement and no heat tag.
• It has no raw material of its own: every BOM line is N/A or a sub-assembly, or the BOM is empty.
• It has a drawing.

The sibling is a live packet in the same unit, with a different id and the same drawing (compared upper-case with white space removed), that has a heat map. The same rev is preferred, then the oldest. The read model gives it as heat_src. It is read-only: nothing on it can be written through the borrowing packet. The screen says "Heat map from on this unit (same drawing). Record heats there."

Shop screens

• GET /api/shop/board covers the shop departments where the person is lead or supervisor. Admin sees every active shop department. A department outside that scope is 403 forbidden. A person who leads no department gets 403 forbidden "You do not lead a department." The change order list also shows open change orders anywhere that wait on one of the person's departments.
• GET /api/shop/stations lists the stations the person may pick for the Stall screen: every station of their shop departments at any level, cut to their station limits for a worker. Admin gets every station.
• GET /api/shop/stall?station_id= is 403 for a station not in that list. Admin passes.

Presence

The packet page shows who else has the packet open. Presence comes over SSE and carries the user id, display name, screen and packet id only.

History texts

The action and note columns of packet_log for each shop write. A department is shown as code and name (03 Weld Parts), except in the verify text, which uses the name only. The station name is as stored (Stall 3).

Write	action	note
assign	Sent to Stall 3	Andy Welder [75] (the stamp in brackets when set)
unassign	Taken off Stall 3
pull_back	Pulled back from Stall 3
start	Work started	Stall 3
submit	Submitted to supervisor	4 welds · 1.5 h
return_to_station	Returned to Stall 3	the reason
send_to_qc	Sent to Q.C.	Spool at Bay 2 · note
route_from_review	Routed to 09 Hydro	Supervisor, Q.C. skipped · from 03 Weld Parts
send_back_to_warehouse	Sent back to the warehouse	the reason
return_to_clerical	Sent back to Clerical	the reason
Weld added	Weld W4 marked	Fillet 5/16" · items 1 + 2 · L662001 #1
Weld edited	Weld W4 changed	the changed fields, type Groove · items 1 + 3
Weld moved (position only)	Weld W4 moved
Weld removed	Weld W4 removed	the reason
Heat tag	Heat tag H2 placed, Heat tag H2 changed, Heat tag H2 moved, Heat tag H2 removed	item 3
Heat table placed	Heat table placed on drawing	the page's dwg, else sheet 2
Heat table moved	Heat table moved	the same
Heat table resized	Heat table resized	A+ or A- and the new size, A+ 1.15
Heat table removed	Heat table removed from drawing	the same
Heat table copied on a change order	Heat table copied to new sheet	from the VOID copy, check its position on the new revision
Checklist	Checked: <item text>, Unchecked: <item text>
Stage fields	Weld record changed	the changed fields, filler ER70S-6 · filler lot 1234
Clock	Clock started, Paused, Resumed
Change order issued	Change order CO-2 issued
Change order approved	Change order CO-2 approved
Change order rejected	Change order CO-2 rejected	the reason
Change order hold	Change order CO-2 holds the packet, Change order CO-2 no longer holds the packet
Change order verified	Change order CO-2 verified by Weld Parts	note · still waiting on Hydro, or note · change order fully verified

The submit hours are the stage's clock_elapsed_ms after the stop, with one decimal.

Q.C. (phase 6)

Who inspects

Q.C. holds a packet in status qc. EDIT_QC (QC, status qc) covers every write to the open inspection: the check items, the visual result per weld, the NDE fields, hardness, the inspector name, the stamp and the notes. A write with no open inspection is 409 no_inspection.

Write	Endpoint	Concurrency
One check item	PUT /api/packets/{id}/qc/checks/{key} {done}	one key by jsonb_set under the packet row lock, no If-Match. Unknown key 422 invalid_key.
One weld's visual result	PUT /api/packets/{id}/qc/welds/{no} {result?, note?}	one weld by jsonb_set. The weld must be live on the packet (422 invalid_weld). result is accept, reject or empty.
The other fields	PATCH /api/packets/{id}/qc {set, base}	field-level compare-and-set over inspector, stamp, nde_method, nde_result, nde_report, hardness, notes; 409 field_conflict with the current value.

nde_method must be one of None required, RT, UT, MT, PT (422 invalid_field "Pick an NDE method from the list."). nde_result is empty, Acceptable or Rejectable. Setting the method to None required clears the result and the report number. The phase 2 flat body (with If-Match on the inspection's row_version, merging checks and weld_exam) still works; a body with set selects the field compare-and-set. The NDE rules apply to both. Hardness is labelled Hardness (NACE) when the packet's WPS contains NACE. The server computes this; no request sets it.

Accept

Two actions accept. Both are Q.C. from status qc, held by an open change order, gated by qc_missing_empty, and signed.

Route	Action	Body	Result
Clerical – Data Book	qc_accept	routed_to: "databook"	complete, routed to the data book
Shipping	qc_accept	routed_to: "shipping"	complete, routed to Shipping
A shop department	qc_accept_and_route	dept: "09"	ready in that department, a new stage opened

The signature meanings are "Q.C. accept" and "Q.C. accept and route". The accept closes the inspection into qc_history and closes the stage with the inspection as its qc_snapshot. The note in the log counts every live weld of the packet.

What Q.C. still needs

qc_missing_empty reads the list built by checklists.qc_missing(). Its message is Q.C. still needs: followed by the parts joined by , and a full stop. blocked.qc_accept and blocked.qc_accept_and_route carry it, so the screen shows Accept disabled with the reason.

Part	When
3 inspection items	that many check items are not done
2 welds without a visual result	that many live welds have no accept or reject
a rejected weld (reject the packet instead)	any weld is rejected
NDE result	an NDE method other than None required is set and the result is not Acceptable
inspector name	the inspector is empty

Reject

qc_reject is Q.C. from status qc back to review, signed ("Q.C. reject"). It takes a reason, an NCR number, or both:

• An NCR number goes through validate_ncr: trimmed, upper case, then the pattern NCR- four digits - four digits. A bad one is 422 invalid_ncr "Enter an NCR number like NCR-2026-0021."
• The reason checked by reason_given is the NCR alone (NCR-2026-0021) when no text is given, else NCR-2026-0021 · <reason>. So an NCR number stands in for the reason, and the text has no minimum when an NCR is given.
• With neither, the answer is 400 reason_required with the rule's message. A reason without an NCR needs 8 characters.

The reject stores the NCR on the inspection, sets the packet's return_note to the reason, and closes the inspection into qc_history at once. The packet in review has no open inspection; the read model gives the reject as qc_last, and the screens show the "Q.C. rejected" callout from it. The supervisor's next send to Q.C. opens a fresh inspection.

The change-order hold applies to both accepts and to file. It does not apply to the reject: Q.C. can always send a packet back.

The NCR link is https://ncr.pescoinc.biz/ncrs/<number>. domain/ncr.py validate_ncr is the hook for checking the number against pesco-ncr. Today it accepts any well-formed number. The check against pesco-ncr is a later phase.

Packet documents

DOC_ADD and DOC_REMOVE are Clerical or Q.C. (CL_OR_QC), in any status but filed (the filed lock applies).

• POST /api/packets/{id}/docs {asset_id, kind, title?, note?}. kind is one of the nine kinds (see SCHEMA.md, "Packet documents"); any other is 422 invalid_kind "Pick a document type from the list." The asset must be a PDF, PNG or JPEG (422 invalid_asset). The title defaults to the kind's label and is up to 160 characters. The note is up to 300 characters.
• DELETE /api/packets/{id}/docs/{doc_id} {reason} takes a document out of the data book. The reason needs 3 characters after cleaning (400 reason_required "Say why it comes out of the data book."). The row is kept with who, when and why. A second take-out is 409 already_removed.

Drawings are never packet documents. They come from M-Files or the hand attach only.

Q.C. folder documents

QC_DOC_ADD is Clerical or Q.C. (CL_OR_QC), checked with check_scoped(). POST /api/qc/docs {project_id | unit_id, type, title?, rev?, note?, asset_id, replaces?, it_reason?}:

• Exactly one of project_id and unit_id (422 invalid_request).
• type is one of ITP, WPS / PQR, NDE procedure, Hydrotest procedure, PMI / material, Calibration certificate, Customer spec, Other (422 invalid_type "Pick a document type from the list.").
• The asset must be a PDF, PNG or JPEG (422 invalid_asset). Limits: title 140 (defaults to the type), rev 12, note 600.
• replaces files a new revision. The replaced row must be a current document of the same folder (422 invalid_replace). One that already points at a newer row is 409 already_superseded. The old row is kept and points at the new one. Nothing is deleted.

Reads (GET /api/qc/home, /api/qc/folders, the project and unit folder reads) need any signed-in session. PM reads and changes nothing.

Clerical may add Q.C. folder documents. The old build allowed Q.C. and Admin only. This is wider than the old build; Seth can narrow it to QC.

The ITP

Each unit has at most one digital ITP, started from the code template ITP_Generation_Revised_2 and frozen at start. Reads (GET /api/units/{unit_id}/itp) need any session. Every write runs check_scoped() with its action, then finds the ITP (404), then refuses a complete one (409 itp_complete), locks the itps row, bumps itps.version once, and writes one itp_log row per change, one audit row for each (itp.<action value>, so itp.itp_start, itp.itp_line_sign; subject itp; detail {text, note, unit_id}, plus signature_id on a signed one) and a change event, in one transaction. Block sign and sign-off check their gates before the signature, so a refused step costs no PIN attempt, and check them again under the lock.

Every line and block row is made at start. A Q.C. user's packet read still lists the scoped actions in can; they mean nothing on a packet.

Action	Who	Endpoint	Gate
itp_start	QC	POST /api/units/{unit_id}/itp	409 itp_exists when the unit has one
itp_edit_line	QC	PATCH /api/itps/{id} (header), PATCH .../lines/{key}, POST .../sections/{n}/na, POST .../lines/{key}/reject, POST .../lines/{key}/ncr, PATCH .../blocks/{key}	see below
itp_line_sign	QC	POST /api/itps/{id}/lines/{key}/sign	the line is not approved (409 already_signed) or N/A (409 line_na); a rejected line needs its NCR (409 ncr_required "Enter the NCR # before approving this line.")
itp_line_unsign	QC	POST /api/itps/{id}/lines/{key}/unsign	the line is approved (409 not_signed); only the inspector who initialed it, or an admin (403 forbidden "Only the inspector who initialed this line, or an admin, can remove it."); refused while the block is signed (409 block_signed "Undo the section signature first.")
itp_block_sign	QC, signature "Sign an ITP block"	POST /api/itps/{id}/blocks/{key}/sign	every line of the block done (409 block_not_ready "Every line must be initialed or N/A first."); not already signed (409 already_signed)
itp_block_unsign	QC	DELETE /api/itps/{id}/blocks/{key}/sign	the block is signed (409 not_signed); the signer or an admin (403 forbidden "Only the inspector who signed this block, or an admin, can remove it."); clears the signature and keeps the block's fields
itp_sign_off	QC, signature "Sign off the ITP"	POST /api/itps/{id}/signoff	every block signed (409 blocks_unsigned "Every section must be signed first.")
itp_reopen	QC_SUP, or an admin through the bypass	POST /api/itps/{id}/reopen {reason, it_reason?}	a reason of 8 characters; the ITP is complete (409 itp_open "The ITP is open already."). An admin who gives no it_reason has the reason used as both.

Line approval is a compare-and-set: the itps row lock, the state check above, and an optional If-Match: <line row_version> (409 row_conflict). Approval sets result approve, by, at and the initials (the first letter of each word of the display name, upper case, at most three). Unsign clears the result, the approver, the time and the initials, so the line is open again. The line's ncr and every itp_rejects row stay.

The itp_edit_line writes:

• Header (no, client, pname, pno, po, unit): field compare-and-set with {set, base} (409 field_conflict), 120 characters each. no cannot be empty (422 invalid_field).
• Line details: na is refused on an approved line (409 already_signed) or one with an open reject (409 line_rejected). cust_code is one of R, R/AU, AU, W, H, NA, or empty for the template's (422 invalid_field "Pick a customer code from the list."). cust_by 80, note 500. cust_at defaults to today when a name is given. A change that changes nothing writes no log and no version.
• Section N/A: sets or clears N/A on every line of the section. Marking N/A is refused when any line of the section is approved (409 already_signed) or has an open reject (409 line_rejected).
• Reject: refused on a line that is approved (409 already_signed), N/A (409 line_na) or already rejected (409 line_rejected). The NCR is optional and validated when given. An itp_rejects row (kind reject) is added.
• NCR entered later: the line must have an open reject without an NCR (409 no_open_reject). An itp_rejects row (kind ncr) is added.
• Block fields: qn 40, remarks 400, cust_name 80, cust_at (today when a name is given), cust_clear clears the customer entry. An empty cust_name without cust_clear is 422 invalid_field "Enter the customer rep's name." No signature.

A write to a complete ITP, other than the reopen, is 409 itp_complete "The ITP is signed off and locked. An admin can reopen it." The sign-off sets status complete and calls the phase 7 hook pdf.itp.file_signed_itp_pdf(). Today the hook returns nothing. When it returns an asset, the sign-off sets signoff_asset_id and files a qc_docs row on the unit (type ITP, auto), superseding any earlier automatic ITP document of the unit. A reopen sets status open with the reason. Block and line signatures stay; the inspector undoes what must change.

ITP actions never look at a packet. A filed packet in the unit does not lock the ITP, because the ITP belongs to the unit (the phase 5 follow-up, open question 28).

Blocks

A signature block closes at every template section marked to sign, and covers the sections since the last block. The template gives blocks 3 (sections 1 to 3), 4, 5, 6, 7, 8 and 9 (the final block). A line is done when it is N/A or approved. A block is ready when every line in it is done, so a block of N/A lines only can be signed.

Hold points

A hold code is H or W, alone or after a slash (R/H), on the PESCO code or the customer code (the line's own customer code when set, else the template's). An open hold point is a line with a hold code that is not done, or any rejected line.

The packet read gives itp_hold while the unit's ITP is open: the open hold and rejected points, filtered by the packet's department page group. It is a warning only. No precondition reads it, and no step is blocked by it. Q.C. and the shop check with each other before moving past a point.

Department	Pages it sees
01, 02, 03, 04, 05, 10	WP (Weld Parts)
06, 07, 13	C (Code)
09	WP and C
08, 11, 12, 14	FA (Final Assembly)
CL, WH, QC, or an unknown code	every page

Log texts

The action and note of packet_log for each Q.C. packet write.

Write	action	note
Check ticked	Q.C. checked: <item text>
Check unticked	Q.C. unchecked: <item text>
Visual result set	VT accept · W3, VT reject · W3	the note when given
Visual result cleared	VT cleared · W3
Weld note only	Q.C. record changed	W3 note
NDE method	NDE method: RT, NDE method: - when cleared
NDE result	NDE result: Acceptable, NDE result: - when cleared (no line of its own when None required cleared it)
Other Q.C. fields	Q.C. record changed	the changed fields, inspector Quinn QC · stamp Q1 · hardness 198 HB · report RPT-1 · notes changed (<field> cleared, notes cleared)
Flat-body checks or weld exam merge	Q.C. record changed
qc_accept to the data book	Q.C. accepted → Clerical – Data Book	Quinn QC [Q1] · 3 welds VT accepted, plus · RT Acceptable when an NDE method other than None required is set, plus · <note> when the step carries a note
qc_accept to Shipping	Q.C. accepted → Shipping	the same
qc_accept_and_route	Q.C. accepted → 09 Hydro	Quinn QC [Q1] · from 03 Weld Parts
qc_reject	Q.C. rejected → supervisor	NCR-2026-0021 · <reason> · welds W1, W3 (parts present only; the rejected welds by number)
Document added	Document added	<label> · <title> · <file name>
Document taken out	Document taken out of the data book	<title> · <reason>

One PATCH that changes several kinds of field writes one line for each. The arrow and the en dash in Clerical – Data Book are the old build's texts. The stamp shows in brackets only when set. The inspector is the inspection's inspector field.

The action and note of itp_log (and the audit row's detail.text) for each ITP write. Dates are M/D/YYYY in America/Denver.

Write	action	note
Start	ITP started	L073028-ITP · template ITP_Generation_Revised_2
Header field	ITP header changed; ITP plan no. changed for no	client: ACME; the new number for no
Line approved	ITP line 1.3 approved	after NCR NCR-2026-0021 when the line was rejected before
Line unsigned	ITP line 1.3 initial removed	was Quinn QC 10/17/2026
Line details	ITP line 1.3 updated	the changes joined by , : marked N/A, applies again, customer code W, customer code as template, customer Rick Inspector, customer cleared, customer date 10/17/2026, note
Line rejected	ITP line 1.3 rejected	NCR NCR-2026-0021 · <note> or NCR # pending · <note>
NCR entered later	ITP line 1.3 NCR number entered	NCR NCR-2026-0021
Section N/A	ITP section 5 marked N/A, ITP section 5 applies again	the section title
Block fields	ITP block 3 QN # changed, ITP block 3 remarks changed	the value
Block signed	ITP block 3 signed	Sections 1–3 or Section 4
Block unsigned	ITP block 3 signature removed
Customer complete	ITP block 3 customer complete recorded, ITP block 3 customer complete cleared	Rick Inspector (the cleared name on a clear)
Sign-off	ITP signed off	PDF filed when the hook filed one, else PDF filing reserved for phase 7
Reopen	ITP reopened	the reason

A Q.C. folder document writes an audit row qc_doc.add or qc_doc.revise (subject qc_doc), with doc_id, project_id, unit_id and replaces in the detail, detail.text Q.C. document added or Q.C. document revised and detail.note L670 · WPS / PQR · WPS-101 GTAW/SMAW Rev 2 · wps.pdf.

Worker writes (phase 3)

The worker has no session. It writes through the same policy as a person, as the system principal Principal(user_id=None, system="visual-feed"). Each write locks the packet row (FOR UPDATE SKIP LOCKED; a row locked by someone else is left for the next run), builds the packet state, runs policy.check(), makes its change, bumps version, and writes a packet_log row (by nobody, by name "VISUAL feed", role system), an audit row (packet.<action>, role system) and a change event. See FEED.md for when each write happens.

Action	From	What the worker does
vis_update_draft	draft	Updates a draft made by the feed: work orders, BOM (unless uploaded by hand), drawing and rev, dates, flags, drawing pages from M-Files.
vis_retire_draft	draft	Soft-removes an untouched draft whose work orders all moved to another packet, reason moved.
vis_open_co	any but draft and filed	Opens, re-aims or withdraws the packet's one pending feed change order, stages a drawing on it, and records drawing flags on a packet past draft.
vis_auto_release	draft to warehouse	Sends a ready draft to the warehouse. Same preconditions as send_to_warehouse (heat map answered, drawing attached). The feed only picks drafts with no flags and the rev confirmed by the drawing job.

What the feed may write:

• Drafts it made, in place, through vis_update_draft and vis_retire_draft.
• New drafts, projects and units (created_by null, audit role system).
• The order-derived fields of projects and units, only where the value came from VISUAL. A value Clerical typed is never overwritten.
• On packets past draft: only a change order (vis_open_co), the observed VISUAL state (leg statuses, closed, cancelled, work order gone, ticket hours) and the drawing flags.
• Its own tables: the caches, drawing_lookups, the job tables.

What the feed may never write:

• Shop-side tables: stages, welds, heat tags, checklists, the clock, warehouse pulls and shorts, Q.C. records, seals. In-shop packets only get a change order.
• A removed packet. A key whose packets are all removed is never made again.
• A filed packet.
• Any person's action. The system principal passes only the vis_* actions, and people can never take them.
• VISUAL or M-Files. Both libraries are read-only.

Rev approval

When M-Files has a different released rev from VISUAL, the drawing job stages the M-Files copy. A Clerical Supervisor (PS-Clerical-Supervisor) can approve it on a draft with rev_approve: a reason of at least 8 characters and a signature ("Approve the M-Files revision"). The pages are attached and the approval is kept on the packet (visual.rev_ok). With nothing staged the answer is 409 nothing_staged.

Hand uploads on flagged drafts

On a draft made by the feed that is flagged (or already has a hand upload), Clerical can upload a drawing (edit_document_set) or a BOM (edit_bom) by hand. Both need a reason and a signature. A hand drawing sets drawing_state hand and flag hand_drawing; a hand BOM sets flag hand_bom and the feed stops replacing the BOM. An unflagged draft refuses with 409 not_flagged. Auto-release never takes a hand-flagged draft, so a person sends it on. "Use VISUAL's BOM again" removes the hand BOM.

Change orders from the feed

• A pending feed change order holds nothing, unless Clerical puts it on hold (co_hold_toggle). Then it blocks the held steps until released or decided.
• Approval (co_approve, Clerical, signature) applies the staged change to the packet: work orders, BOM, drawing and rev. When the drawing changed, the new drawing must be staged first (co_staged_if_dwg_change, 409 co_not_staged). The old drawing pages are voided, not deleted.
• After approval a major change order asks the departments it touches to verify (co_verify), and holds the packet until they have.
• A minor change order (only target hours or the want date changed) needs Clerical approval only. No department is asked to verify, so it holds nothing after approval.
• Rejection (co_reject) needs a reason and a signature. The feed does not reopen a change order Clerical rejected for the same target.

Tightenings against the old build

The old policy was looser than the old screens in places. The rebuild follows the screens where they were stricter, and the README where it states the intent. Each row is a change Seth can veto.

What the old build allowed	What the rebuild does	Why	Can be vetoed
A department lead could write welds, BOM, heat tags, the checklist, stage fields and the clock through the policy whenever the packet was in a shop status.	These edits need the holder of the packet (the holder rule, applied as the old screens did). A lead of another department cannot.	The screens only offered these to the holder. The policy now matches.	Yes
Any worker in the department within their station limits could start or submit a packet (worksOn ignored who was assigned).	START and SUBMIT need the assigned welder for a worker. Leads and supervisors still can.	The README says only the assigned worker.	Yes
A status change could carry any other field in the same save.	A transition carries only its own fields (the step's inputs). Other changes go through their own edit actions and rules.	One rule per write keeps the check honest.	No
Clerical "lead" actions (approve an M-Files rev mismatch, move back from VISUAL review) were open to any Clerical member with a lead flag.	REV_APPROVE and moving back from VISUAL review need Clerical Supervisor (PS-Clerical-Supervisor).	There is no Clerical lead AD group.	Yes
A packet routed to Shipping had no path to filed.	Complete packets routed to Shipping get the same Clerical close and file path. Only the Data Book route needs the VISUAL close before filing.	Shipping packets were stuck at complete.	Yes
Anyone could set the data book date, even on a filed packet.	SET_DATABOOK_AT is Clerical or Q.C. only (open question 17). It stays allowed on a filed packet.	The data book date is a Clerical and Q.C. record.	Yes
Change-order verifications were stored in the packet document, with no rule against changing them later.	Verifications need a signature, are insert-only and cannot be withdrawn (open question 18).	A signed verification is a record.	Yes
The old policy did not look at the BOM when the warehouse released a packet.	WH_RELEASE needs every BOM line not marked n/a to be pulled or to have an open short.	A packet should reach the shop with its material, or with the shorts on record.	Yes
The old screen asked for a heat number on every pulled line before release, but the policy did not check it.	WH_RELEASE also needs a heat on every pulled line that issued pieces, unless the line is N/A or a sub-assembly (heats_recorded), checked on the server.	Traceability is the point of the pull. The screen alone could be skipped.	Yes
Hold reasons and short reasons were any text the screen sent.	Both are closed sets checked on the server. "Other" on a hold needs a note.	The board and the shorts table group and report on the reason, so it must be one of the list.	Yes
A hand draft could leave Clerical with no drawing (the packet PDF upload stood in for it).	A hand draft needs a drawing attached before any send from Clerical.	There is no packet PDF upload in the rebuild.	Yes
Attaching drawing pages by hand needed no signature.	Attaching a drawing by hand needs a signature ("Attach a drawing by hand").	It replaces what M-Files would supply, so a person stands behind it.	Yes
Admin could write anything on a filed packet with an IT reason.	Admin cannot write a filed packet except through ADMIN_REOPEN (with a reason and a signature), and SET_DATABOOK_AT.	A filed packet is sealed. A change breaks the seal on purpose, on record.	No
Admin passed every check after the change-order hold, so an admin could make a step from any status.	Admin goes through the same status check. The bypass covers who and custody only. Preconditions still apply.	Admin fixes data, not the workflow order.	Yes
A hand drawing or BOM upload on a flagged VISUAL draft took a reason of 3 characters and a PIN sign-off checked in the browser.	Both need a reason of at least 8 characters and a signature verified on the server, kept on the packet with who and when.	A hand upload stands in for VISUAL or M-Files, so a person stands behind it.	Yes
Approving a different M-Files rev was open to a Clerical lead.	rev_approve needs Clerical Supervisor, with a reason and a signature.	There is no Clerical lead AD group, and the approval overrides VISUAL.	Yes
The Sync on a Clerical PC skipped removed packets ("removed here, not re-made"), but only as the browser saw them.	A removed packet's key is never recreated, whatever VISUAL says. The match runs on the server across live and removed rows, in the feed's transaction.	A removal is a decision. The feed does not undo it.	No
The Sync saved through the same packet document that held the shop's work, so nothing but the code kept it off the shop's fields.	The feed never writes shop-side tables. Packets past draft only get a change order, observed VISUAL state and drawing flags.	The shop's record is the shop's.	No
The assign sheet only offered welders of the department and filtered the stations by the welder's limits. The policy checked neither.	ASSIGN checks on the server that the welder has a shop role in the packet's department, and that a limited worker's station is one of their stations.	The picker alone could be skipped.	Yes
The old screen asked for a weld of the current department before submit, but the policy did not check welds.	welds_recorded counts the welds of the packet's current department, on the server. After a route the new department marks its own.	Each department records its own welds.	Yes
A mark could be placed on a VOID sheet.	A VOID sheet refuses new marks and moves (422 void_page). The marks already there stay.	Marks belong on the current revision.	Yes
The station clock ran in the browser, and the elapsed time was saved from the browser.	The server keeps the clock with the database time. No request sets the elapsed time.	The clock is a record. A browser clock can be wrong or changed.	No
Packet document kinds and Q.C. folder document types were whatever the screen sent.	Both are closed sets checked on the server (and by a CHECK in the database).	The data book sorts and labels by kind and type.	Yes
A packet document could be taken out of the data book with no reason.	A take-out needs a reason of at least 3 characters. The row is kept with who, when and why.	A document leaving the record is a decision on record.	Yes
A Q.C. reject took any non-empty text.	A reject needs a reason of at least 8 characters, or a well-formed NCR number, or both (open question 27).	A short note like "no" says nothing to the supervisor. An NCR number points to the full record.	Yes
An ITP line rejected without an NCR could not be approved only because the screen disabled the button.	The server refuses the approval until the NCR number is entered (409 ncr_required).	The screen alone could be skipped.	Yes
ITP block signatures and the sign-off were PIN checks in the browser.	Both are signatures verified on the server and stored with a content hash.	A signature is a record.	No
The ITP sign-off was offered when the screen saw every block signed.	The sign-off is a server rule: every block signed (409 blocks_unsigned), and a complete ITP refuses every write but the reopen.	The screen alone could be skipped.	Yes
The screen limited removing an ITP line's initials to the same inspector or an admin, and refused it while the block was signed. Nothing else checked.	The server enforces both (open question 18).	The initials are that inspector's record. The screen alone could be skipped.	Yes
Any Q.C. user could remove a block signature.	Only the signer or an admin, while the ITP is open (open question 30).	A signature is that person's record.	Yes