This is an internal working record, not an everyday instruction. It was written while the system was being rebuilt, for whoever maintains it. If you are here to do today's work, use the everyday documents instead: Procedures · Processes · Runbooks · The working day, step by step

MK Physical Scale Policy Decision Matrix¶

Status: CURRENT DECISION INPUT / NO APPROVAL IMPLIED
Process: PROC-YMS-SCALE-TICKET-EXECUTION-MK
Reconciliation: MK_PHYSICAL_SCALE_RECONCILIATION.md
Rebuild packet: MK_PHYSICAL_SCALE_CAPABILITY_REBUILD_PACKET.md
Source authority: MK_PHYSICAL_SCALE_SOURCE_AUTHORITY.md
Operating profile: mk-order
Decision owner: Product/process/operations/role/data/device owners by row
Important: recommendation is not implementation authorization, Process approval, Wiki publication or Production policy.

1. Decision States¶

RECOMMENDED
OPEN
ACCEPTED
REJECTED
RUNTIME EVIDENCE REQUIRED
DEVICE EVIDENCE REQUIRED
DEFERRED
SUPERSEDED

A row is implementation-ready only when:

the accountable owner accepts it;
dependent rows are accepted;
required Runtime/device/role/schema evidence exists;
rollback and caller impact are defined.

2. Blocking Decision Summary¶

ID	Decision	Current source	Recommendation	Owner	State	Blocks
`SCALE-POL-010`	stage direction per flow	UI matrix conflicts with integrated Check-in	Purchase/Doortrade Gross→Tare; Sales/Export Tare→Gross, subject to owner/field proof	Product + Scale + Inbound + Outbound	RUNTIME EVIDENCE REQUIRED	every Scale write wave
`SCALE-POL-020`	`Other/Walk-In` scope	fallback/demo and walk-in controls exist	remove from normal MK operations unless a bounded owner/use case is accepted	Product + Operations	OPEN	UI/API/Wiki
`SCALE-POL-030`	zero-weight behavior	current source rejects zero	forbid by default; only an explicit exception command may allow it	Product + Operations	RECOMMENDED	validation/device
`SCALE-POL-040`	reading source	manual current; no device contract	manual remains supported; device is optional separate capability	Product + Device + Operations	OPEN	device wave
`SCALE-POL-050`	physical event time	ticket DB time; some order writes browser time	server accepted time is canonical; preserve optional device captured time separately	Data + Process	RECOMMENDED	field/schema/migration
`SCALE-POL-060`	Check-out owner Save	browser sequential header/items	introduce owner `PrepareScaleCheckOut` atomic contract or explicit bounded child results	Inbound + Outbound + Scale	RECOMMENDED	Check-out migration
`SCALE-POL-070`	Outbound close	later separate update	keep separate owner result with close-only recovery	Outbound + Scale	RECOMMENDED	UI/Runbook/M4
`SCALE-POL-080`	Purchase finalize	later branch/finalize	keep separate owner result with finalize-only recovery	Inbound + Scale	RECOMMENDED	UI/Runbook/M4
`SCALE-POL-090`	reweigh authority	same Scale menu path	separate `yms.scale.reweigh`; reason always required for changed stage	Role + Operations	RECOMMENDED	access/M4
`SCALE-POL-100`	void/reversal authority	YMS guarded; BMS generic differs	YMS recovery command is sole MK owner; reason, event and blocker checks required	Product + Role + Scale	RECOMMENDED	recovery/caller-zero
`SCALE-POL-110`	BMS generic writer	same ticket table, weaker contract	retire for MK YMS scope or define provably disjoint records	P5 + BMS + YMS	OPEN	one-writer/caller-zero
`SCALE-POL-120`	ticket number allocation	latest/max + 1	atomic tenant-scoped reservation bound to request token	Data + Scale	RECOMMENDED	concurrency/write cutover
`SCALE-POL-130`	completed-ticket visibility	completed ticket leaves open board	target UI retains exact completed readback and event timeline	Product + P7 + Operations	RECOMMENDED	UI/Wiki
`SCALE-POL-140`	demo rows	auto-injected when operational board empty	remove from operational mode; explicit demo/test mode only	Product + Operations	RECOMMENDED	operator safety
`SCALE-POL-150`	signatures/bad-bale fields	shared legacy ticket columns	assign separate owner/retention or exclude from initial Scale migration	Product + Data + Security	OPEN	schema/UI
`SCALE-POL-160`	action-level access	module/menu only	semantic view/check-in/check-out/reweigh/reverse/events/print/reconcile capabilities	P2-007 + Role owner	RECOMMENDED	role Gate
`SCALE-POL-170`	request idempotency	no durable business token	required for Check-in, Check-out, correction and reversal	Application + Data	RECOMMENDED	write activation
`SCALE-POL-180`	freshness/version	partial current stage CAS only	version/fingerprint for ticket and owner snapshot	Application + Data	RECOMMENDED	concurrency/recovery
`SCALE-POL-190`	canonical UOM and precision	current integer LB	LB canonical initially; exact conversion policy before other units	Product + Data	RECOMMENDED	device/PostgreSQL
`SCALE-POL-200`	device reading retention	none	retain accepted reading reference; raw payload only by bounded security/retention policy	Device + Security + Data	DEFERRED	device wave
`SCALE-POL-210`	print effect	browser output only	remain nondurable unless Product introduces print acknowledgement	Product + Operations	RECOMMENDED	Wiki/document design
`SCALE-POL-220`	reversal downstream blockers	broad current checks	preserve broad default; owner matrix explicitly enumerates blockers and compensations	Scale + Inbound + Outbound + Inventory	RECOMMENDED	reversal activation
`SCALE-POL-230`	Ticket Number edit	current projection can be rewritten indirectly	immutable after ticket creation; correction requires separate exceptional policy	Product + Data	RECOMMENDED	field/API
`SCALE-POL-240`	manual fallback marking	manual is current default	record `source=MANUAL`; device path records accepted reading ID	Product + Device + Audit	RECOMMENDED	device/UI/audit

3. Flow And Stage Policy¶

`SCALE-POL-010` — accepted entry/exit stage per flow¶

Current conflict¶

UI policy:
Purchase/Doortrade = Gross -> Tare
Sales/Export = Tare -> Gross

Integrated Check-in:
Gross for all flows

Recommended target¶

Flow	Entry	Exit	Minimum linked context
Purchase	Gross	Tare	Purchase order/items; Transload link
Doortrade	Gross	Tare	accepted local inbound order/items; Transload link
Sales	Tare	Gross	Sales order/items; Equipment Load link
Export	Tare	Gross	Sales order/items; Booking/container/size; Equipment Load link

Acceptance evidence¶

normal UI entry through target role;
exact API payload;
exact persisted stage/time/axles;
active-board inclusion after entry;
successful opposite-stage Check-out;
rejection of wrong stage;
event and cleanup evidence.

Stop condition¶

Do not activate or migrate Scale writes while this row remains unresolved.

4. Walk-In And Demo Policy¶

`SCALE-POL-020` — `Other/Walk-In`¶

Current UI offers Doortrade, Export, Purchase and Sales quick actions and has an OTHER fallback. It can create order shells depending on flow.

Recommended decision:

normal business flow
or
explicit test/demo/exception flow

Do not leave OTHER as an implicit default that guesses stage direction and owner.

Required questions:

Does a physical movement without an accepted Purchase/Sales record exist?
Which domain owns that record?
Is an order created before the ticket?
Which company/commodity/equipment fields are required?
Which stage direction applies?
How is it billed/documented?

`SCALE-POL-140` — demo cards¶

Current empty-board behavior creates interactive demo cards. Recommended target:

Operational empty state:
No open Scale tickets

Demo mode:
explicit environment/config/banner
no Production mutation
no ambiguity with operational rows

5. Weight And Unit Policy¶

`SCALE-POL-030` — zero weight¶

Recommendation:

zero and negative stage totals are forbidden by default;
Tare greater than Gross is forbidden for completed tickets;
exceptional zero-weight handling, if business-required, is a named command with reason, actor and bounded flow—not a numeric tenant branch.

`SCALE-POL-190` — UOM and precision¶

Initial target:

input UOM: LB
canonical UOM: LB
display UOM: profile/user projection
stage axle precision: exact accepted integer LB parity for current migration

Before supporting MT/LT/ST/EACH conversion for Scale values, accept:

conversion source/version;
rounding mode;
precision;
minimum tolerance;
storage versus display values;
correction/reversal behavior.

Order-item UOM is not automatically the physical Scale UOM.

6. Device Policy¶

`SCALE-POL-040` — device scope¶

Options:

Option	Meaning	Recommendation
A	manual-only first migration	preferred initial React/Next.js parity path
B	device adapter in same migration	only with concrete hardware/protocol/field evidence
C	device display only, manual acceptance	acceptable intermediate if provenance and stale/unstable behavior are explicit

`SCALE-POL-200` — reading storage¶

Recommended minimum:

stable device ID;
device session ID;
immutable reading ID;
captured/received time;
input/canonical UOM;
value/stability;
accepted-by actor and accepted-at time;
ticket stage reference.

Raw serial/network payload retention is optional and security-sensitive.

`SCALE-POL-240` — manual fallback¶

Every accepted stage identifies its source:

MANUAL
DEVICE

A device failure does not silently convert to manual input. The operator explicitly chooses the fallback or stops.

7. Time Policy¶

`SCALE-POL-050`¶

Current source mixes DB stage time with browser-generated order time.

Recommended target fields/concepts:

deviceCapturedAt        optional
serverReceivedAt        optional device transport evidence
stageAcceptedAt         canonical business stage time
requestCreatedAt        request trace only
ownerCloseAt            owning Order process time

Rules:

stageAcceptedAt is server-authoritative;
browser clock is not canonical;
device-captured time never replaces accepted server time silently;
all times use explicit tenant/business timezone projection and UTC-compatible persistence rules;
Purchase/Outbound owner times remain separately owned.

8. Check-out Composition Policy¶

`SCALE-POL-060`¶

Current browser writes owner header/items sequentially.

Recommended target:

PrepareScaleCheckOut
= one owner command per Order family
= allowed header/item changes
= exact item set
= version/freshness
= atomic owner readback

Then:

CompleteScaleCheckOut
= ticket stage only

Then:

FinalizePurchaseReceiptFromScale
or
CloseOutboundFromScale

The UI may guide these continuously, but child results remain independent.

9. Downstream Handoff Policy¶

`SCALE-POL-070` — Outbound close¶

Recommendation:

Scale completion does not set Outbound complete inside the Scale transaction;
Outbound owner validates its own record/version/state;
close command returns exact result;
Scale UI displays Scale complete / Outbound close pending|failed;
recovery invokes only Outbound close.

`SCALE-POL-080` — Purchase finalize¶

Recommendation:

Purchase finalize remains Inbound-owned;
branch intent and receipt/lot results are explicit;
checkout never replays when finalize fails;
target UI supports reopen/finalize-only recovery;
multi-line source/lot behavior is proven before M4.

10. Access Policy¶

`SCALE-POL-160`¶

Proposed matrix:

Capability	Normal role candidate	Manager/support candidate	Notes
`yms.scale.view`	Scale Operator	Manager/Support	tenant/record scope
`yms.scale.check-in`	Scale Operator	Manager	accepted flow and record
`yms.scale.check-out`	Scale Operator	Manager	valid entry required
`yms.scale.reweigh`	policy-dependent	Manager	reason required
`yms.scale.reverse`	no ordinary operator by default	Manager/Recovery	downstream guard
`yms.scale.events.view`	Scale Operator summary	Manager/Support full	bounded sensitive data
`yms.scale.print`	Scale Operator	Manager	active tenant-scoped ticket
`yms.scale.reconcile`	no ordinary operator	Support/Recovery	unknown/BMS conflict
`yms.scale.device.use`	Scale Operator	Device Support	only when device enabled

Final mapping must come from P2-007 live role/page/API/record evidence, not numeric role IDs.

11. Reweigh And Reversal Policy¶

`SCALE-POL-090` — reweigh¶

Recommended rules:

entry stage exists;
exit stage absent;
actor has reweigh capability;
reason required;
expected ticket version required;
new stage values validated;
ticket update and event append in one transaction;
no generic edit after completion.

`SCALE-POL-100` — void/reversal¶

Recommended language:

VOID
= ticket not physically completed

REVERSAL
= completed ticket withdrawn through controlled recovery

Both require reason and event. Reversal after downstream execution is blocked unless an accepted cross-owner compensation plan exists.

`SCALE-POL-220` — downstream blockers¶

At minimum inspect:

Purchase Transload progress/final values/location/equipment;
Inventory Lot and Ledger;
Outbound Equipment Load and Scale linkage;
Delivery/Transload use;
order times/status;
billing/document evidence if Product later treats them as blockers.

A blocker does not authorize direct cleanup. It assigns recovery to the owning process.

12. Competing Writer Policy¶

`SCALE-POL-110`¶

Current alternatives:

Option A — retire BMS generic write for MK YMS tickets¶

Preferred.

BMS read/history may remain
MK physical writes -> YMS Scale owner only

Option B — disjoint record scope¶

Acceptable only if exact record classification, role/page/API guard and tests prove BMS cannot mutate YMS-owned MK tickets.

Rejected target¶

YMS and BMS both mutate the same MK ticket
with different correction/reversal/link rules

Before caller-zero record:

all BMS UI/API/job callers;
exact ticket types/tenants;
PATCH/delete fields;
linked Transload/equipment effects;
audit/log consumers;
rollback path.

13. Identity And Concurrency Policy¶

`SCALE-POL-120` — ticket number¶

Requirements:

tenant-scoped uniqueness;
concurrency-safe allocation;
request-token binding;
exact existing result on duplicate retry;
no client-generated substitute.

`SCALE-POL-170` — request token¶

Required for:

Check-in
Check-out
Entry correction
Void/reversal

Key:

tenant + command type + scaleRequestToken

Same token/same canonical payload returns existing result. Same token/different payload conflicts.

`SCALE-POL-180` — version/freshness¶

Ticket commands use:

expected ticket version or accepted stage fingerprint;
owner order/item snapshot version where relevant;
exact link version/existence;
conditional update predicates.

No FOR UPDATE in Runtime SQL per repository DB rules.

14. Completed Readback And Print Policy¶

`SCALE-POL-130`¶

Target UI retains:

completed ticket detail;
Gross/Tare/Net;
entry/exit times;
flow;
order/link identity;
event timeline;
downstream child disposition;
print action.

Absence from the active board is not the only completion evidence.

`SCALE-POL-210`¶

Print remains a projection unless Product explicitly introduces a durable acknowledgement process.

print opened
!= print completed
!= Scale completed
!= owner process completed

15. Legacy Field Policy¶

`SCALE-POL-150`¶

Fields requiring owner/disposition:

DRIVER_SIGNATURE
WEIGHER_SIGNATURE
BAD_BALE_DESCRIPTION_1..3
BAD_BALE_QUANTITY_1..3
BAD_BALE_WEIGHT_1..3

Questions:

Are signatures operationally used?
Are they personal/sensitive data requiring retention/access controls?
Are bad-bale fields Scale-owned, Quality-owned or CTC-only compatibility?
Must they move in the initial MK migration?
Which outputs consume them?

Until decided, do not expand these fields in the new core Scale UI.

16. Decision Dependency Graph¶

flowchart TD
    Flow[SCALE-POL-010 Flow Direction]
    Role[SCALE-POL-160 Access]
    Idem[SCALE-POL-170 Idempotency]
    Version[SCALE-POL-180 Freshness]
    Number[SCALE-POL-120 Ticket Number]
    Checkout[SCALE-POL-060 Checkout Composition]
    Inbound[SCALE-POL-080 Purchase Finalize]
    Outbound[SCALE-POL-070 Outbound Close]
    Reweigh[SCALE-POL-090 Reweigh]
    Reverse[SCALE-POL-100 Reversal]
    BMS[SCALE-POL-110 BMS Writer]
    Device[SCALE-POL-040 Device Scope]
    M4[Scale Write Migration]

    Flow --> M4
    Role --> M4
    Idem --> M4
    Version --> M4
    Number --> M4
    Checkout --> M4
    Inbound --> M4
    Outbound --> M4
    Reweigh --> M4
    Reverse --> M4
    BMS --> M4
    Device -. optional .-> M4

17. Activation Gate¶

A Scale writer wave remains blocked while any of these is unresolved:

SCALE-POL-010 flow direction
SCALE-POL-060 Check-out owner preparation
SCALE-POL-100/110 reversal and competing writer
SCALE-POL-120/170/180 number, idempotency and freshness
SCALE-POL-160 action-level access
SCALE-POL-070/080 child recovery

Device policy can be deferred when the accepted initial migration is manual-entry-only.

18. Decision Evidence Template¶

policy ID
decision and alternatives
owner/reviewer
decision date
source and Runtime evidence
roles/tenants/flows affected
data/schema/interface/UI/Wiki impact
migration/rollback impact
accepted result
unresolved exceptions
implementation Task/wave
verification scenario IDs

Do not encode an open recommendation as a schema field, React branch, numeric Client condition or operator instruction.

---¶

Source: docs/processes/MK_PHYSICAL_SCALE_POLICY_DECISION_MATRIX.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.

MK Physical Scale Policy Decision Matrix¶

1. Decision States¶

2. Blocking Decision Summary¶

3. Flow And Stage Policy¶

SCALE-POL-010 — accepted entry/exit stage per flow¶

Current conflict¶

Recommended target¶

Acceptance evidence¶

Stop condition¶

4. Walk-In And Demo Policy¶

SCALE-POL-020 — Other/Walk-In¶

SCALE-POL-140 — demo cards¶

5. Weight And Unit Policy¶

SCALE-POL-030 — zero weight¶

SCALE-POL-190 — UOM and precision¶

6. Device Policy¶

SCALE-POL-040 — device scope¶

SCALE-POL-200 — reading storage¶

SCALE-POL-240 — manual fallback¶

7. Time Policy¶

SCALE-POL-050¶

8. Check-out Composition Policy¶

SCALE-POL-060¶

9. Downstream Handoff Policy¶

SCALE-POL-070 — Outbound close¶

SCALE-POL-080 — Purchase finalize¶

10. Access Policy¶

SCALE-POL-160¶

11. Reweigh And Reversal Policy¶

SCALE-POL-090 — reweigh¶

SCALE-POL-100 — void/reversal¶

SCALE-POL-220 — downstream blockers¶

12. Competing Writer Policy¶

SCALE-POL-110¶

Option A — retire BMS generic write for MK YMS tickets¶

Option B — disjoint record scope¶

Rejected target¶

13. Identity And Concurrency Policy¶

SCALE-POL-120 — ticket number¶

SCALE-POL-170 — request token¶

SCALE-POL-180 — version/freshness¶

14. Completed Readback And Print Policy¶

SCALE-POL-130¶

SCALE-POL-210¶

15. Legacy Field Policy¶

SCALE-POL-150¶

16. Decision Dependency Graph¶

17. Activation Gate¶

18. Decision Evidence Template¶

---¶

`SCALE-POL-010` — accepted entry/exit stage per flow¶

`SCALE-POL-020` — `Other/Walk-In`¶

`SCALE-POL-140` — demo cards¶

`SCALE-POL-030` — zero weight¶

`SCALE-POL-190` — UOM and precision¶

`SCALE-POL-040` — device scope¶

`SCALE-POL-200` — reading storage¶

`SCALE-POL-240` — manual fallback¶

`SCALE-POL-050`¶

`SCALE-POL-060`¶

`SCALE-POL-070` — Outbound close¶

`SCALE-POL-080` — Purchase finalize¶

`SCALE-POL-160`¶

`SCALE-POL-090` — reweigh¶

`SCALE-POL-100` — void/reversal¶

`SCALE-POL-220` — downstream blockers¶

`SCALE-POL-110`¶

`SCALE-POL-120` — ticket number¶

`SCALE-POL-170` — request token¶

`SCALE-POL-180` — version/freshness¶

`SCALE-POL-130`¶

`SCALE-POL-210`¶

`SCALE-POL-150`¶