Make the next rule precise
A later change starts with an agreed business reason and a specific rule. Name the affected people, records and operating decisions. AI can implement the change, but the business owner must decide its consequences for work already in progress.
In this illustrative equipment change, Finance approval follows ordinary approval for new requests above €1,000. This is a company policy chosen for the example, not a Soda OS default.
- Initial rule
- An authorised reviewer approves another person’s request before Operations records delivery.
- New rule
- For new requests above €1,000, ordinary approval locks the reviewed positive EUR amount and moves the request to Awaiting Finance. Finance approval then permits delivery. Exactly €1,000 follows the ordinary path. The Finance approver differs from both requester and initial approver, even when people hold multiple roles.
- What stays protected
- Earlier requests, including pending ones, retain their original workflow and decisions. Display the applicable policy. Refuse repeated decisions, changes to the reviewed amount, and delivery before every required approval.
Choose a preservation rule for each change
Equipment uses a new-requests-only policy. Onboarding deliberately allows some unfinished existing work to adopt relative deadlines. Neither is a universal strategy for old records.
An onboarding task can have a fixed date or a calendar-day offset from the start date. Existing tasks keep their explicit dates until HR deliberately converts unfinished work. Calendar days include weekends; working-day and holiday conventions need separate decisions.
HR previews the old and proposed start dates, changed deadlines, unchanged fixed dates and protected completed tasks. It explicitly confirms past-due consequences. Confirmation applies the start date and eligible dates together; cancellation preserves both. Every start-date change route follows this rule.
Only unfinished relative tasks move. Fixed dates and completed task dates stay unchanged; assignment and access remain intact. Keep the calculated dates visible rather than silently shifting them to today. Retain before/after dates with the schedule change.
Task and conditionEquipment preparation — unfinished, three calendar days before joining
- Before
- 5 March
- After confirmation
- 12 March
Relative date moves
Task and conditionHandbook reading — unfinished, on joining date
- Before
- 8 March
- After confirmation
- 15 March
Relative date moves
Task and conditionWelcome session — fixed appointment
- Before
- 18 March
- After confirmation
- 18 March
Original date stays
Task and conditionEmergency contacts — completed
- Before
- 5 March
- After confirmation
- 5 March; completion unchanged
Original date stays
Write a before/after change brief
State how the rule applies to new, pending and completed records separately. Include what must remain intact, how exceptional existing values will be handled and who approves the rollout. Record uncertainty as a decision to resolve, not an instruction for AI to invent company policy.
Blank before/after change brief
Copy this template to define a rule change and decide how existing work will be treated.
Change context
- Reason
- What changed in the business?
- Affected actors and data
- Who and which records are affected?
Before and after
- Before rule
- Describe today’s behavior.
- After rule
- State the new rule, boundaries and exceptions.
Existing and new work
- New records
- Which policy applies, and from when?
- Pending records
- Keep, convert or review? Who decides?
- Completed records
- What remains protected?
Preservation, checks and rollout
- Permissions and history to preserve
- Name access, decisions, original values and audit facts.
- Permitted and refused acceptance cases
- Try the changed rule and existing behavior, including boundary values.
- Rollout and operating decisions
- Name approval, operator, deployment, data handling and recovery decisions.
Filled equipment change brief
An illustrative Finance approval change with separate policies for new, pending and completed requests.
Change context
- Reason
- Add financial control for higher-value new requests.
- Affected actors and data
- Requester, reviewer, Finance and coordinator; requests, reviewed EUR amounts and decisions.
Before and after
- Before rule
- An authorised reviewer approves another person’s request before Operations records delivery.
- After rule
- For new requests above €1,000, ordinary approval locks the reviewed positive EUR amount and moves the request to Awaiting Finance. Finance approval then permits delivery. Exactly €1,000 follows the ordinary path. The Finance approver differs from both requester and initial approver, even when people hold multiple roles.
Existing and new work
- New records
- Use the new policy after its agreed effective point.
- Pending records
- Earlier requests retain their original workflow.
- Completed records
- Earlier delivered requests and all recorded decisions remain protected.
Preservation, checks and rollout
- Permissions and history
- Earlier requests, including pending ones, retain their original workflow and decisions. Display the applicable policy. Refuse repeated decisions, changes to the reviewed amount, and delivery before every required approval.
- Acceptance
- Test below, exactly at and above €1,000, separate actors, locked amount and delivery guard.
- Rollout and operation
- Agree effective point, policy display, operator, deployment checks and recovery procedure.
Check changed and existing work
Review the exact candidate and check the running application against the change brief. Try a successful case and an expected refusal for each affected actor and state. Repeat the relevant existing-work checks so that a new feature does not silently weaken an earlier rule.
A browser reload checks a different boundary from an application rebuild or deployment. Verify storage and model-change handling against the selected runtime and procedure; do not infer it from a persistent development Project or a saved preview record. Plan incompatible earlier values deliberately. This method promises no automatic migration or rollback.
Amount boundaries
New equipment requests: €450 and exactly €1,000 follow ordinary approval; €1,400 waits for Finance after ordinary approval.
Approval safeguards
Refuse Finance approval by the requester or initial approver, changes to the reviewed amount, repeated decisions and early delivery.
Earlier requests
Earlier pending and completed equipment requests retain their original workflow and records.
Existing task dates
Onboarding: existing dates stay until deliberate conversion; confirm calendar-day calculations and past-due effects.
Cancel the preview
Cancel a start-date preview and confirm the start date and all task dates remain unchanged.
Confirm the change
Confirm a schedule change and check only unfinished relative tasks move; fixed dates, completed records and permissions remain intact.
Preserve the right history
Returned expenses need a linked replacement, not an overwritten submission. A reviewer returns another person’s Submitted claim with a reason. The original stays unchanged and cannot progress to approval or payment. Only its submitter creates at most one direct replacement; every replacement receives fresh approval. Approval and payment facts are never copied forward. Approved and paid claims remain protected.
Recurring maintenance needs a new report, not a reopened or rewritten repair. A technician links an open ticket to an earlier resolved ticket at the same location and records why. Changing or removing the link while open retains actor, time and reason; the relationship is protected after resolution. Each ticket keeps its own history. A linked reference and preview require access to both records.
Each record retains its own history and access rules.
Authored illustration of workflow rules and responsibilities.