Cross-module implementation paper

Apply payroll relationship reasoning · 1 point

• Time for each assignment can deliver to that assignment’s payroll
• Only the primary assignment delivers time; the rest is informational
• Both assignments must share one payroll or neither will process
• Time is split evenly between the two payrolls

Judge whether a recorded claim is checkable · 1 point

• It names a source, the release it was verified against, and when — so somebody else can repeat the check
• It comes from somebody with implementation experience
• It matches what you already believe about the process
• It has been repeated in more than one place

Reason across a module boundary · 2 points

• The hand-off between Time and Labor and payroll — the bridge and the payroll relationship
• The time entry rules, which validate before anything else
• Consumer validation, which runs after calculation
• The worker’s repeating time period

Reason about evidence under configuration change · 2 points

• Recorded evidence of what changed, verification that it worked, and a rollback path
• A second identical consumer set, in case the first is needed later
• A change request approved by the tenant administrator
• Nothing further, if the configuration saved without error

Judge what must be re-verified after a release change · 2 points

• Every statement whose recorded release scope names the previous release
• None — a completed upgrade does not change documented behaviour
• Only the statements about payroll, because payroll changes most often
• Only statements a learner has already read

Sequence a configuration change in a live tenant · 2 points

• Record the current state, change one thing, verify the effect, and write down how to reverse it
• Change everything related in one maintenance window, then verify once at the end
• Test the change in a sandbox first, then apply it to the tenant exactly as tested
• Apply it, then write the documentation afterwards so it reflects what was actually done