Authority and Error Model

The technical PDF states there are no core HasAuthority checks; the setup PDF says they exist. The current components implement CheckPawn, checking cached PawnRef and PawnRef.HasAuthority, and numerical helpers/activation use it. There is no plugin RPC transport, so remote input still needs the project Server RPC layer.

Not every mutation invokes CheckPawn: food and temperature tag setters, stamina add/remove tags, temperature modifier setters and all AppendCrossAffect/RemoveCrossAffect implementations lack a uniform authority guard. Public BlueprintReadWrite state properties also allow bypassing intended mutation rules. Keep every write on authority and validate the calling project action.

Positive numerical inputs are commonly checked and values are clamped in several health/food/stamina paths, contrary to the PDF's blanket assertion of no implicit correction. Temperature is not min/max-clamped. There is no consistent finite-number validation, shared result structure or transaction/rollback mechanism.

Most mutations return void. Invalid values may return silently, while invalid Pawn/authority logs an error. Some routing failures (missing component/map key) simply return. A log or successful Blueprint call execution does not establish that a requested change occurred; query actual authoritative state where the integration needs confirmation.

Use the Implementation Limits findings to define project acceptance tests. The plugin source was not repaired during documentation work.