Meridian Payments · Idempotent refund submission
A refund submitted twice against the same order is applied twice. The behavior is not a defect against the written requirement, because the requirement never decided whether refund submission is idempotent. Meridian wants the slice delivered inside one planning interval, and wants to know who signs what before it starts.
ScopeThe slice is headless. No design-fidelity claim arises, so the pod runs four delivery seats rather than five.
Who is on this engagement
Two hats have no name against them. That is deliberate, and stage 1 is where it has to be noticed.
Delivery pod
4 seats
- Priyanka Raman · Spec owner
- Owns Define, product intent and scope.
- Tomas Lind · Evaluation lead
- Owns evaluation design, thresholds and false-pass controls.
- Ada Mensah · Technical boundary lead
- Owns the technical specification, architecture and technical correctness.
- Joel Fairweather · Implementation owner
- Owns construction, review response and release boundaries.
Workbench platform
2 seats
- Rohan Iyer · Agent operations lead
- Owns workflows, runbooks, supervision and recovery.
- Unassigned · Platform and data lead
- Deliberately vacant at the start. Stage 1 has to notice.
Client authority
6 seats
- Dana Okafor · Outcome counterparty
- Director of payments product. Countersigns intent and accepts or rejects.
- Sam Beaulieu · Client release authority
- Release management. Authorises canary and production promotion.
- Grace Whitfield · Domain SME
- Payments operations. Holds the retry behavior nobody wrote down.
- Idris Khan · Data owner
- Data governance. Owns ledger semantics, lineage and retention.
- Mei Lin · Delivery coordinator
- Program management. Owns feature order and tracking on the client side.
- Unassigned · Client evaluation counterpart
- Meridian QE has not named anyone. Stage 1 has to notice.
Governance
2 seats
- Ruth Almeida · Executive sponsor
- VP engineering at Meridian. Mandate, funding, terminal escalation.
- Casey Lindqvist · Delivery lead
- Cadence, reporting, commercials, escalation. No Judge signature.
What exists, and what it is silent about
- Outcome signal
- Duplicate refunds appear in the ledger after a client retry. Raised by payments operations, not by a test.
- Product spec
- Drafted by the spec owner. Silent on whether a second submission with the same key is a no-op or a second refund.
- Technical spec
- Names the ledger invariant but assumes the policy question is already answered.
- Evaluation plan
- Property run over 500 generated retry sequences. No production replay corpus exists.
- Evidence bundle
- Clean property run, one refuted scan finding, and silence on the policy class.
- Confidence package
- Four claims ready to sign. The fifth is contested.
The Judge that does not resolve itself
Do not resolve this before stage 5
The property run is clean over 500 generated sequences, and the evaluation lead will sign evidence sufficiency only with a stated material limitation: no production retry corpus exists, so the claim is statistical, not proof. The outcome counterparty wants to accept. The client release authority has not yet been asked, because promotion is a separate decision that nobody has scheduled. The data owner has not seen the ledger retention change at all.
The question stage 5 answersWho signs, who is consulted, what does the signed claim actually say, and what stops this feature reaching production on the strength of a green run?