At a Glance
Persona: Audit / Config (Auditor read-only + System Administrator config) · Module: purchase-request · Scenarios: ~30
Categories: Happy Path · Permission · Validation · Edge Case
E2E coverage: no dedicated30X-pr-audit-config-journey.spec.tsyet; audit-log read paths partly viatests/301-pr.spec.tsactivity-log assertions in../carmen-inventory-frontend-e2e/
This page captures the test scenarios that the Audit / Config persona axis drives in the purchase-request module. Two roles share this axis even though they sit on opposite sides of the read / write divide: the Auditor is a read-only persona who walks the immutable activity trail (workflow_history, tb_purchase_request_comment per PR_POST_008, line-level current_stage_status history, vendor / pricelist / exchange-rate snapshots from PR_CALC_006) to verify policy compliance, segregation of duties, and trail completeness; the System Administrator is a configuration persona who owns workflow stages, amount thresholds (PR_AUTH_005), delegation rules and windows (PR_AUTH_006), per-PR-type defaults, tax / currency masters feeding PR_CALC_002–PR_CALC_006, and user / role assignments on user_action.execute[]. Neither role sits on the request-to-PO happy path. Scenarios are grouped into the happy paths from 03-user-flow-audit-config.md Section 2 (Auditor: query PRs by period, drill into the activity log, export with secondary approval, flag a policy violation; Sysadmin: change a workflow stage, adjust a threshold, set up a delegation window, change a PR-type default, change tax / currency masters), the RBAC boundaries from PR_AUTH_002, PR_AUTH_005–PR_AUTH_008 in 02-business-rules.md Section 4, the validation rules that fire on each surface (snapshot preservation per PR_CALC_006, export-approval policy, configuration-deadlock prevention, threshold range checks, date-range scan limits), and a set of boundary cases unique to having both a passive audit surface and an active configuration surface. Cross-persona handoffs that pivot off the Audit / Config axis (Auditor case-file escalation that triggers a Sysadmin PR_AUTH_007 void, Sysadmin rollback affecting subsequent Requestor submissions) live in the parent overview, not here.
Section 1 mixes Auditor and Sysadmin happy paths. Auditor scenarios (AUD-HP-01 to AUD-HP-04) verify read-only query, drill-down, export with secondary approval, and policy-violation flagging. Sysadmin scenarios (AUD-HP-05 to AUD-HP-09) verify workflow / threshold / delegation / PR-type-default / tax-and-currency-master changes.
| # | Scenario | Pre-condition | Steps | Expected |
|---|---|---|---|---|
| AUD-HP-01 | Auditor queries PRs by date range and PR type (read-only) | Auditor auditor@blueledgers.com logged in with the auditor role grant; at least 50 PRs in workflow_history for the target window; no active export request |
1. Sidebar → Audit → PR Activity Queries. 2. Select template "All status transitions for a PR" (or build an ad-hoc query). 3. Apply filters: pr_date between 2026-04-01 and 2026-04-30, enum_purchase_request_type = general_purchase, business unit = BU-HQ. 4. Click Run query. |
Result table renders one row per PR with pr_no, requestor, current pr_status, last action, last actor, threshold-breach flag, and total event count; sort and pagination work; the click-through to the drill-down page is available; no writes hit tb_purchase_request; the query itself is logged in the audit-side query log with the Auditor's user_id, the filter set, and the result count. |
| AUD-HP-02 | Auditor drills into a specific PR and walks the full activity trail | Auditor opened a result row from AUD-HP-01; target PR PR-202604-0042 is in pr_status = approved after a 3-stage approval chain with one send-back hop and one delegation event |
1. Click pr_no to open the drill-down page. 2. Read the status timeline: every workflow_history row in chronological order with stage entered / cleared, actor user_id, and any type = system or type = user comment. 3. Inspect line-level current_stage_status history for each of the 8 detail rows. 4. Inspect snapshot fields: vendor_id, vendor_name, pricelist_detail_id, pricelist_price, exchange_rate per PR_CALC_006. 5. Confirm trail is contiguous (no out-of-order timestamps, no gaps between created_at and current state). |
Timeline renders end-to-end with no UI errors; the send-back hop is annotated with PR_POST_003 source and reason text; the delegation event shows both the delegating user and the delegate per PR_AUTH_006; line-level decisions match header-level decisions per PR_AUTH_003; the snapshot fields match the recorded exchange_rate and pricelist_price at submit / approval times; no PR state changes; the drill-down view itself is logged in the audit query log. |
| AUD-HP-03 | Auditor exports a period report including sensitive fields (requires secondary approval) | Auditor has built a query that returns 120 PRs with sensitive fields (requester_name, full free-text justification, vendor pricelist snapshots); a data-export approver export-approver@blueledgers.com is configured |
1. Click Export → CSV with sensitive fields. 2. Fill the export request form: purpose "Q2 internal audit — vendor-pricing anomaly review", period, scope. 3. Click Submit for approval. 4. Export-approver receives notification, opens the request, reviews scope, clicks Approve. 5. Auditor returns to the case file, finds the export in approved state, clicks Download. |
Export is created in pending state on submit; download link is not materialised until approval; on approval, the file is materialised (CSV with row-level data, headers, and audit metadata: query filters, approver user_id, approval timestamp); the audit-side export log records: requester, approver, scope hash, file checksum; no PR state changes; the case file links the export object for future reference. |
| AUD-HP-04 | Auditor flags a PR as a policy violation in the audit case file | Auditor's drill-down on PR-202604-0099 reveals an approval recorded against a user not in user_action.execute[] for that stage (anomaly suspected); evidence ready to attach |
1. On the drill-down page, click Flag in case file. 2. Fill the flag form: reason "Approval recorded outside user_action.execute[] for Stage 2 — suspected misrouted notification or stale token", attach the timeline screenshot and a workflow_history excerpt. 3. Set the routing target = Compliance (out-of-band business owner). 4. Click Save flag. |
Flag is written to the audit-side case file only; tb_purchase_request, workflow_history, and tb_purchase_request_comment on the PR are unchanged (pr_status stays at whatever it was; no audit-comment row is appended); the Compliance owner is notified out-of-band; the case file shows the new flag with the Auditor's user_id; the PR detail page is unaffected for transactional personas; per PR_AUTH_007, any remediation that requires changing PR state is performed by the System Administrator, not the Auditor. |
| AUD-HP-05 | Sysadmin changes a workflow stage — add a new Stage 4 high-value approver | Sysadmin sysadmin@blueledgers.com logged in with the sysadmin role grant; change ticket CHG-2026-118 open; current workflow has 3 stages; Finance has approved adding a 4th stage procurement_manager for base_total_amount > 100,000 ฿ |
1. Configuration workspace → PR Workflow Settings → open workflow WF-GENERAL-BU-HQ. 2. Add Stage 4 with stage_role = approve, assigned users = pm@blueledgers.com, threshold trigger = base_total_amount > 100,000 ฿. 3. Preview panel shows: 0 in-flight PRs affected (snapshot preserved per PR_CALC_006), forecast of 12 new PRs/month routing to Stage 4 based on recent volume. 4. Click Save. 5. Confirm in the dialog. |
New configuration version written with effective_from = <save timestamp>; old version archived with effective_to; configuration audit log records the diff with Sysadmin's user_id, change ticket reference, and stage-list delta; affected user populations (pm@blueledgers.com) notified; PRs already in_progress keep the old 3-stage snapshot; new PRs created after effective_from use the 4-stage chain with PR_AUTH_005 threshold routing; the change is visible to the Auditor in the configuration audit log. |
| AUD-HP-06 | Sysadmin adjusts an amount threshold (PR_AUTH_005) |
Current escalation threshold to the Procurement Manager stage is > 100,000 ฿; Finance memo requests lowering to > 75,000 ฿; ticket CHG-2026-122 open |
1. PR Workflow Settings → open the same workflow → Threshold Rules panel. 2. Change escalation_threshold from 100000 to 75000 ฿. 3. Preview panel shows: 14 in-flight PRs in the [75k, 100k] band that would have routed differently (none re-route per snapshot semantics), forecast of 6 additional PRs/month escalating to Stage 4. 4. Click Save. 5. Confirm. |
Threshold value updated with new effective_from; configuration audit log records the prior value 100000, new value 75000, ticket reference, and delta forecast; in-flight PRs in the [75k, 100k] band continue under the old threshold band per the snapshot preservation pattern; new PRs in that band created after effective_from route to Stage 4. The PR_AUTH_005 comparison operator (strict >) is unchanged — only the threshold value moves. |
| AUD-HP-07 | Sysadmin sets up a delegation window (PR_AUTH_006) |
Approver hod@blueledgers.com going on leave 2026-06-01 to 2026-06-14; delegate hod-delegate@blueledgers.com agreed; ticket CHG-2026-130 open |
1. Configuration → Delegation Rules → Add delegation. 2. Pick delegating user hod@blueledgers.com, delegate hod-delegate@blueledgers.com, window start_at = 2026-06-01 00:00, end_at = 2026-06-14 23:59, scope = all stages owned by the delegating user. 3. Preview panel shows: 3 PRs currently at stages owned by the delegating user (they will be re-fanned to the delegate on start_at), 0 conflicts with other delegations. 4. Click Save. 5. Confirm. |
Delegation row written with start_at, end_at, delegate user_id, and scope; user_action.execute[] of affected stages is augmented (not replaced) per PR_AUTH_006 — both users remain eligible during the window; configuration audit log records the delegation creation; on start_at an activation event re-fans pending notifications to the delegate; on end_at the delegate's inherited rights drop and the delegating user's queue restores naturally — no PR re-routing required. |
| AUD-HP-08 | Sysadmin changes a PR-type default (default workflow, default tax treatment) | New PR type capital_expense added by the business; needs a different default workflow and vat_inclusive = false as line default; ticket CHG-2026-141 open |
1. Configuration → PR Type Defaults → select enum_purchase_request_type = capital_expense. 2. Set default workflow = WF-CAPEX-BU-HQ, default vat_inclusive = false, default currency_id = base currency THB. 3. Preview panel shows: 0 in-flight capital_expense PRs (new enum value), forecast of 4 PRs/month. 4. Click Save. 5. Confirm. |
New PR-type-default row written with effective_from; configuration audit log records the diff; new capital_expense PRs created after effective_from inherit the new defaults at submit time (consumed by PR_CALC_002–PR_CALC_004 for tax and PR_CALC_006 for currency); existing PRs of other types are unaffected; the change is visible to the Auditor in the configuration audit log. |
| AUD-HP-09 | Sysadmin changes a tax-code or currency-rate master | Tax rate for code VAT_STANDARD changes from 7% to 7.5% effective 2026-07-01; new FX rate row for USD → THB added for the same date; ticket CHG-2026-150 open |
1. Configuration → Tax Codes → open VAT_STANDARD → add new rate row 7.5% effective_from = 2026-07-01. 2. Configuration → Currency Rates → add row USD → THB rate 34.85 effective_from = 2026-07-01. 3. Preview panel shows in-flight PR count touched by either master (all of them retain their snapshotted rates per PR_CALC_006). 4. Save each change. |
Two configuration rows written, each with their own effective_from; configuration audit log records both changes; in-flight PRs keep the old rates as vat_rate and exchange_rate snapshots per PR_CALC_002–PR_CALC_006; new PRs submitted on or after effective_from consume the new rates; the Auditor sees the master-change rows in the audit log and can correlate them with PR snapshots to verify the snapshot pattern held. |
Section 2 splits Auditor (read-only allow / write deny) from Sysadmin (configure allow / transact deny) cases.
| # | Scenario | Expected behaviour (allow/deny + reason) |
|---|---|---|
| AUD-PERM-01 | Auditor opens the activity log of any PR in scope | Allow read-only. The auditor role grants read on tb_purchase_request, tb_purchase_request_detail, workflow_history, tb_purchase_request_comment, and user_action. No mutation rights are granted; the action bar on the PR detail page is hidden for the Auditor. The drill-down itself is logged in the audit-side query log. |
| AUD-PERM-02 | Auditor attempts to edit a PR, change approved_qty, or click Approve / Reject / Send Back / Void |
Deny — read-only role. PR_AUTH_002 requires the user to be in user_action.execute[] for the current stage; the Auditor is never in that list by configuration. The UI hides write controls; a direct API call to PATCH /pr/:id or to any workflow action endpoint is rejected with "You are not authorised to act on this PR — auditor role is read-only". |
| AUD-PERM-03 | Sysadmin opens PR Workflow Settings and saves a stage / threshold / delegation change | Allow. The sysadmin role grants write on workflow configuration tables, threshold rule tables, delegation tables, PR-type-default tables, and tax / currency master tables. Every save writes to the configuration audit log with the Sysadmin's user_id. PR_AUTH_007 and PR_AUTH_008 analog: configuration scope is held exclusively by sysadmin. |
| AUD-PERM-04 | Sysadmin attempts to approve / reject / send-back a PR (transactional action) | Deny — wrong role. The Sysadmin is not in user_action.execute[] for any transactional stage by default (unless explicitly assigned as a separate user grant, which is discouraged for segregation of duties). UI hides the Approve / Reject / Send Back buttons; a direct API call is rejected by PR_AUTH_002 with "You are not authorised to act on this PR at the current stage — sysadmin role does not include transactional approval". The only PR-state-changing action a Sysadmin can perform is the elevated void under PR_AUTH_007 (see AUD-PERM-06). |
| AUD-PERM-05 | Auditor exports a CSV / PDF report that includes sensitive fields | Allow, gated on secondary approval. The Auditor can submit an export request; the export sits in pending until a configured data-export approver releases it (per AUD-HP-03). UI surfaces the pending state; a direct API call to GET /audit/export/:id/download on a pending export is rejected with "Export is pending approval". Non-sensitive scoped exports (e.g. a count-only report) bypass the secondary approval but are still logged. |
| AUD-PERM-06 | Sysadmin performs an elevated void on an in-flight or approved PR (PR_AUTH_007) |
Allow with audit trail. PR_AUTH_007 reserves the void action to the Sysadmin / Finance scope. The Sysadmin opens the PR, clicks Void, types a mandatory reason, confirms. The server runs PR_AUTH_007 → PR_POST_006: pr_status flips to voided (terminal); soft / hard commitments released; workflow_history appended; a type = system comment captures the reason (PR_POST_008); the Auditor sees the void event next time they query. This is the only Sysadmin action that changes PR state — distinct from configuration save. |
| AUD-PERM-07 | Non-auditor user (Requestor / Approver / Purchaser) attempts to open PR Activity Queries | Deny — wrong role. The Audit workspace is restricted to the auditor and sysadmin roles. UI hides the Audit sidebar entry for other roles; a direct route navigation is rejected with "You are not authorised to view the audit workspace". Transactional personas see only their own PRs and the activity log of PRs already in their scope (read-only on those PRs only, via the same activity-log tab, not the query builder). |
Section 3 covers validation failures on both surfaces: Sysadmin configuration writes that violate snapshot, deadlock, range, or window rules; Auditor query / export attempts that violate scan limits or approval gates.
| # | Scenario | Trigger | Expected error |
|---|---|---|---|
| AUD-VAL-01 | Sysadmin attempts a workflow change that would re-route an in-flight PR (snapshot preservation per PR_CALC_006) |
Sysadmin removes Stage 2 from a workflow that has 18 PRs sitting at Stage 2 right now; preview panel shows 18 PRs would be left without a stage if re-routed; Sysadmin clicks Save |
Allowed save, but in-flight PRs keep the old snapshot. Per the snapshot-preservation pattern in 02-business-rules.md Section 6, the save is not blocked; the 18 in-flight PRs continue under the old 3-stage configuration until they exit in_progress; only PRs created after effective_from see the new 2-stage chain. The preview panel surfaces the in-flight count for transparency. Any direct API call attempting to retroactively re-route an in-flight PR (POST /pr/:id/re-route) is rejected with "Cannot re-route an in-flight PR — snapshot preserved per PR_CALC_006". |
| AUD-VAL-02 | Auditor attempts to download a sensitive-fields export without secondary approval | Auditor submits an export including requester_name and full free-text justification; the export-approver has not yet approved; Auditor calls GET /audit/export/:id/download directly |
Reject with "Export is pending approval — sensitive fields require secondary release". UI also disables the Download button until the approver releases the export. The export-approval policy is enforced server-side; there is no UI-only bypass. |
| AUD-VAL-03 | Sysadmin removes the last user from user_action.execute[] on a stage that has an in-flight PR waiting at it (deadlock) |
Workflow Stage 2 currently has one assigned user approver-1@blueledgers.com; one PR is in_progress at Stage 2; Sysadmin opens the editor and removes approver-1@blueledgers.com without assigning a replacement |
Reject pre-save with "Stage 2 has 1 in-flight PR but would have 0 eligible approvers after this change — assign a replacement or activate a delegation before saving". The validator catches the deadlock at validate-before-save time per 03-user-flow-audit-config.md Section 3 decision branch; the Sysadmin must either add a replacement user, activate a PR_AUTH_006 delegation that covers the affected stage, or accept the deadlock with an explicit override toggle that is logged separately in the configuration audit log. |
| AUD-VAL-04 | Sysadmin activates a delegation with end_at < start_at or with start_at in the past |
Sysadmin types start_at = 2026-06-14 00:00, end_at = 2026-06-01 23:59 and clicks Save (window inverted); or start_at = 2026-04-01 00:00 for a window already elapsed |
Reject pre-save with "Delegation end_at must be after start_at" for the inverted window, or "Delegation start_at must be in the future or now" for the elapsed-window case. UI also disables the Save button until the dates are valid. A direct API call is rejected with the same messages. The validator runs per PR_AUTH_006 window semantics. |
| AUD-VAL-05 | Auditor runs a query with no filters or with a date range that exceeds the configured scan limit | Auditor clicks Run query with empty filter chips, or with pr_date between 2020-01-01 and 2026-04-30 (range > configured 12-month limit) |
Reject with "Query must include at least one filter to prevent unbounded scans" for the empty case, or "Date range exceeds 12-month limit — split the query or request an offline export" for the over-range case. The UI also live-validates the date range and disables Run query until the range is within limit. The limit is configurable per organisation; the validator runs at submit time. |
| AUD-VAL-06 | Sysadmin enters an invalid threshold value (negative, zero, non-numeric, or exceeds the per-currency cap) | Sysadmin types escalation_threshold = -50000 for the high-value-routing rule, or escalation_threshold = 0, or pastes "abc", or types a value above the configured per-currency cap 9,999,999,999.99999 ฿ |
Reject pre-save with the appropriate message: "Threshold must be a positive amount" for negative / zero, "Threshold must be numeric" for non-numeric, "Threshold exceeds the configured per-currency cap" for the over-cap case. UI inline-flags the bad input and disables Save. The validator runs the same range / type checks that protect PR_VAL_* on transactional fields. |
| AUD-VAL-07 | Sysadmin saves a configuration change with no diff (no-op save) | Sysadmin opens PR Workflow Settings, makes no edits, clicks Save | Reject with "No changes detected — nothing to save". The configuration writer requires a non-empty diff against the active version; UI disables Save until at least one staged change is present. No new effective_from row is written and no notifications fire. (Mirrors PM-VAL-02.) |
| AUD-VAL-08 | Sysadmin attempts to delete a tax-code or currency-rate row that is referenced by an in-flight PR snapshot | Sysadmin tries to delete VAT_STANDARD row 7% effective_from = 2025-01-01 while 42 in-flight PRs hold that row in their vat_rate snapshot per PR_CALC_002–PR_CALC_004 |
Reject with "Cannot delete tax code in use by 42 in-flight PR snapshots — archive (set effective_to) instead of delete". The validator enforces that master-data rows referenced by any active snapshot can be archived (an effective_to is added so the row no longer applies to new PRs) but never deleted outright. Same pattern protects currency-rate rows, vendor master rows, and pricelist rows. |
Section 4 covers boundary and concurrency cases unique to the audit / config persona axis. AUD-EDGE-01 to AUD-EDGE-03 are configuration-side; AUD-EDGE-04 to AUD-EDGE-06 are audit-side.
| # | Scenario | Condition | Expected |
|---|---|---|---|
| AUD-EDGE-01 | In-flight PR vs new configuration snapshot boundary | PR-A is submitted at T-0 under workflow WF1 and threshold T1. Sysadmin saves WF2 and T2 at T+10m (single change ticket). PR-B is created at T+11m and submitted at T+12m. PR-A approval clears at T+20m |
PR-A clears through WF1's stage chain end-to-end and is evaluated against T1 for escalation — the configuration snapshot taken at submit holds through every approval and into PO conversion. PR-B's workflow snapshot at submit is WF2 with threshold T2. The boundary is the effective_from timestamp of the new configuration, not the time of approval. Mirrors PR_CALC_006 exchange-rate snapshot pattern and PM-EDGE-01 vendor-allocation snapshot pattern. |
| AUD-EDGE-02 | Sysadmin rollback of a bad configuration change | Sysadmin saves WF2 at T. By T+30m, the verify-activation step (03-user-flow-audit-config.md Section 2 step 6) finds that WF2 introduced a routing bug for PR type capital_expense. Sysadmin reverts to WF1 at T+35m. Between T and T+35m, 4 PRs were created under WF2 |
The rollback is itself a configuration save with its own effective_from = T+35m; the configuration audit log records both the forward change (T) and the rollback (T+35m); the 4 PRs created between T and T+35m keep their WF2 snapshot per the snapshot-preservation pattern (snapshot semantics protect them from being retroactively re-routed); new PRs created after T+35m use WF1. The Auditor can correlate the rollback log with the 4 PRs and decide whether each needs an out-of-band remediation (typically: a Sysadmin PR_AUTH_007 void per PR if the misrouting is unrecoverable). |
| AUD-EDGE-03 | Mass-delegation activation at the organisation boundary | A bulk delegation activates at start_at = 2026-06-01 00:00 UTC for 23 approvers across multiple business units. The clock at start_at triggers the activation event; some user sessions are mid-action when the activation fires |
The activation processes delegate-by-delegate in a deterministic order; for each delegating user the system augments user_action.execute[] on all stages they own (per PR_AUTH_006); notifications re-fan in batch but each PR is notified at most once per delegate to prevent storms. Sessions mid-action at activation see the new delegate reflected on their next refresh; in-flight server requests started before activation complete under the pre-activation user_action.execute[] (first-write-wins). The configuration audit log records the bulk activation as a single event with delegate-level breakdown. Operationally rare — bulk delegations are scheduled outside business hours by convention. |
| AUD-EDGE-04 | Auditor finds a gap in the audit log (system event missing) | Drill-down on PR-202604-0077 shows a state transition in_progress → approved at T but no type = system comment row at T to record the action, and no corresponding workflow_history row |
Auditor flags the PR in the case file with the gap evidence (timestamp T, missing rows). The flag does not change PR state. Routing target = Compliance plus a separate tag to the platform team for log integrity review. Per the immutability rule (PR_POST_008), the audit trail is meant to be tamper-evident — a gap is itself a reportable anomaly and the case file becomes evidence. The Sysadmin would not attempt to backfill the missing rows; instead a platform-level investigation is opened. |
| AUD-EDGE-05 | Auditor query exceeds dataset size limit and times out | Auditor runs "All status transitions for a PR" over pr_date 2025-01-01 to 2025-12-31 for all business units with no requestor filter; estimated result count > 500,000 events; the query exceeds the configured timeout |
Server returns "Query exceeds maximum result size — narrow the filter set or split into smaller windows" (or, if timeout fires mid-stream, "Query timed out after Ns — split or schedule as an offline export"). UI surfaces a refinement-suggestion panel: "Try narrowing by business unit, quarter, or PR type." The query is still logged in the audit-side query log as a failed attempt with the filter set and the failure reason — useful for the Auditor's own audit-of-audit review. |
| AUD-EDGE-06 | Configuration save lands exactly at the moment a new PR is being submitted | At T, Requestor clicks Submit on PR-X (triggering snapshot routines for workflow, threshold, tax, currency, vendor); in the same instant T, Sysadmin saves new configuration C2 with effective_from = T |
Tie-break is by the system clock at write time. If PR-X's snapshot routine resolves the configuration at T-1ms, it reads C1; at T+1ms it reads C2. Both outcomes are valid — the contract is "use whichever configuration is effective at the moment of snapshot," not "give PR-X a preferred version." The configuration audit log and the PR's snapshot record both timestamps so the choice is observable to the Auditor. Mirrors PM-EDGE-06. |
PR_AUTH_007 void, Sysadmin configuration changes whose effect surfaces on subsequent Requestor / Approver flows.PR_AUTH_002 per-stage executors, PR_AUTH_005 amount-threshold routing, PR_AUTH_006 delegation window semantics, PR_AUTH_007 elevated void / Sysadmin scope, PR_AUTH_008 enum_stage_role ownership), Section 5 (PR_POST_006 void / reject / cancel, PR_POST_008 immutable audit comments), Section 6 (snapshot semantics for configuration changes, PR_CALC_006 exchange-rate snapshot pattern that workflow / threshold / tax / currency snapshots follow).workflow_history for audit review; threshold-boundary patterns (APP-EDGE-05) the Sysadmin's threshold configuration drives.PM-VAL-03, PM-EDGE-01, PM-EDGE-06) the Audit / Config axis extends to workflow / threshold / delegation / master-data changes.30X-pr-audit-config-journey.spec.ts exists yet. Audit-log read paths are partly exercised through the activity-log assertions in ../carmen-inventory-frontend-e2e/tests/301-pr.spec.ts (per-action transition audit verification). Configuration changes (workflow / threshold / delegation / master data) are out of scope for current PR-module specs and would live in a dedicated configuration test suite. Add a persona-journey spec once the Audit workspace UI and the Configuration workspace UI are wired into the frontend.../carmen/docs/purchase-request-management/PR-Module-Structure.md (configuration surface: workflow stages, thresholds, delegation, PR-type defaults, tax / currency / user-role configuration), ../carmen/docs/purchase-request-management/PR-User-Experience.md (activity-log UX, audit-trail presentation, drill-down conventions), ../carmen/docs/purchase-request-management/PR-Overview.md (Auditor and System Administrator stakeholder roles, governance integration points), ../carmen/docs/purchase-request-management/purchase-request-module-prd.md (product requirements for the audit log, configuration surface, and elevated administrative actions), ../carmen/docs/purchase-request-management/testing.md (testing levels — audit-trail completeness assertions, configuration-change regression patterns), ../carmen/docs/purchase-request-management/troubleshooting.md (Section 2.2 workflow transition issues — frequently the diagnostic surface the Auditor brings to the Sysadmin; Section 2.3 master-data corruption — the route by which AUD-VAL-08 arises).PR_POST_008-style immutable comment pattern.