# Project reframe record

Use this when an inherited promise conflicts with observed work, system behavior, or policy. Preserve the original brief and the decision history. The completed entries below are hypothetical teaching records, not customer evidence or operating authority.

## Boundary and original promise

| Field                        | Hypothetical completed entry                                                                                           |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Workflow                     | Domestic price-variance invoice exceptions                                                                             |
| Engagement boundary          | One approved accounts-payable investigation; no other customer or tenant evidence                                      |
| Original claim               | “Automatically resolve and post eligible invoice exceptions without a separate accounts-payable review.”               |
| Source / class               | Brief B-1 revision 1 / sold                                                                                            |
| Original record state        | Preserved; contested, not silently rewritten                                                                           |
| Access and evidence handling | Permitted redacted evidence in the approved store; existing classification, retention, and deletion requirements apply |

## Competing evidence

| Record                    | Claim class and finding                                                              | Scope / limitation                                                                           |
| ------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| B-1 revision 1            | Sold: automatic posting without separate review                                      | Establishes promise, not authority                                                           |
| O-1 revision 1, case 1042 | Observed: reviewer inspected, corrected, approved, then posted in a separate step    | Establishes what happened in this case, not how often it happens or whether it was permitted |
| P-8 revision 8            | Policy-authorized: designated reviewer approval required before each covered posting | Hypothetical policy confirmed by its owner; actual use must verify current applicability     |
| T-1 revision 1            | System-enforced: teaching build rejects absent or invalid approval                   | Tested fixture behavior only; target platform not established                                |

Conflict: whether the proposed service may post a correction on its own.

## Roles and authority basis

| Role                               | Hypothetical role holder        | Basis and limitation                                                                    |
| ---------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------- |
| Sponsor                            | Finance transformation lead     | Sponsors cycle-time improvement; no posting permission inferred                         |
| Queue owner                        | Accounts-payable exception lead | Owns queue and escalation path; observation does not establish policy                   |
| Operator                           | Accounts-payable reviewer       | Performs correction and review                                                          |
| Person deciding the proposed scope | Accounts-payable service owner  | May accept or reject this delivery boundary; cannot waive another owner's controls      |
| Policy owner / verifier            | Finance controls manager        | Confirms approval policy and checks controls independently of recommendation production |

## Bounded proposal

- Included: classify domestic price-variance exceptions, assemble cited evidence, and stage proposed corrections for review.
- Excluded: autonomous posting, new exception categories, expanded data access, and policy changes.
- Retained authority: designated reviewer approves and controls posting.
- Missing evidence: continue through the manual queue; do not invent a correction.
- Safe path while pending: existing manual queue; only already permitted observation and analysis continue. A new staging prototype needs its own permissions.
- Acceptance change: a correct review-ready proposal that a reviewer can reject; no automatic-completion claim.
- Economics change: include reviewer and verification time; benefit and full cost remain unmeasured.
- Schedule change: revise after reviewer capacity and authorized test scope are known; no invented completion date.

## Requested decision and current state

Current status: **awaiting the service owner's decision**. Using B-1, O-1, and P-8, the service owner is asked to accept, reject, or defer preparation and staging for the specified invoice exceptions. This does not ask them to waive the posting rule. No approval is inferred from this worksheet.

| Answer      | Required record                                                                                             | Conditional next move                                                                                             |
| ----------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Accept      | Who agreed, why they may decide, which work they accepted, why, which evidence versions they used, and when | Plan recommendation and staging inside the accepted boundary; obtain separate data, action, and release approvals |
| Reject      | Rejected proposal and rationale                                                                             | Stop this slice or investigate an explicitly requested alternative; prohibited automatic posting remains blocked  |
| Defer       | Missing evidence, owner, reconsideration condition, review point                                            | Keep manual path and collect only permitted evidence                                                              |
| No decision | Open conflict and affected work                                                                             | Continue permitted discovery or pause affected implementation; silence is not acceptance                          |

## Conditional downstream updates after acceptance

| Artifact            | Reason for review or change                                                | Owner / scope                                      |
| ------------------- | -------------------------------------------------------------------------- | -------------------------------------------------- |
| Workflow boundary   | Posting promise becomes recommendation-and-staging scope                   | Service owner; preserve B-1 as superseded history  |
| Acceptance cases    | Review-ready correctness and reviewer effort replace autonomous completion | Evaluation owner; no lowered controls              |
| Value assumptions   | Review time and uncertain benefit must remain visible                      | Metric owner; re-estimate using evidence           |
| Delivery plan       | Reviewer participation and separate gates become dependencies              | Delivery owner                                     |
| Tool contracts      | Review which records or other external results the tools may change        | Security and system owners; no permissions implied |
| Data contract       | Check whether population, use, and access truly remain unchanged           | Data owner; unchanged only with recorded rationale |
| Unrelated artifacts | No dependency on disputed posting claim                                    | Preserve revisions; do not regenerate by default   |

Reconsider if policy, eligible population, access, or permitted actions change. Accepting the smaller scope does not approve a production release, tool use, data access, or customer acceptance. Any resulting record change still needs a separate check of the authoritative system.

## Your working copy

### Start with these questions

1. What exactly was promised, and where is the original promise recorded?
2. Which observed case, system behavior, or current policy contradicts it?
3. What smaller scope could be considered without crossing that boundary?
4. Who may accept, reject, or defer the proposal, and what stays safe while they decide?

### Preserve the conflict and request a decision

- Which engagement, customer/tenant, workflow, and environment are involved?
- Where may the evidence be kept, and which handling rules apply?
- What exact passage made the original promise? Retain its author, source revision, and commitment.
- Which claims contradict it? For each, record whether it was sold, stated, observed, system-enforced, policy-authorized, or inferred, with its owner, revision, and limitation.
- Which consequential action or decision is disputed, and what safe fallback remains?
- Which authority is needed, who holds it, and what verifies their right to decide?
- What behavior is included or excluded in the proposal, and which decisions stay with people?
- What would change in acceptance, economics, and schedule? Which downstream artifacts depend on the disputed claim?
- What decision is requested, using evidence through which cutoff, and who owns that decision?
- What was decided, by whom, for which work, why, when, and where the decision is recorded:
- What happens if the answer is acceptance, rejection, deferral, or no decision?
- Which dependent records need updating, who owns each, and what would reopen the decision? Which unrelated records and earlier versions stay unchanged?