Req Room

Review — the human-in-the-loop queue

Every escalated column across all five sources, in one queue. The agent asks a question only when no hard check can pin the mapping — resolving one is a judgement call, not a rubber stamp, and the schema below requires a real reason for every decision.

0 of 12 remaining escalations block replay. All five sources currently replay — the human answered every question the agent needed answered.

The agent escalated 16 columns total across five sources. A human resolved 4 of them — and 4 of those were the ones actually blocking replay (a required field with no other covered candidate). The remaining 12stay escalated by design — the point of this queue is answering only what the pipeline needs, not rubber-stamping every column the agent wasn’t certain about. See the audit trail below for exactly which decisions those were and why.

Work queue

Blocking escalations sort first and are marked in red — this is the human’s actual work: the agent asked these questions, not the other 16 columns it already committed with hard evidence.

Audit trail

Every column a human has already resolved, per source — who decided, when, why, and the artifact version the decision produced.

hris

version bump: v1 → v2

  • employee_id → person.personId

    was blocking replay

    Decision: approve · Decided by: thomas.peng · Decided at: 2026-07-12T17:00:00Z

    employee_id is unique across all 254 hris rows (254 distinct values) and every value matches the E-#### identifier shape (E-1001 through E-3121, non-contiguous) that no other column in this export uses. But cardinality and shape are proxies, not proof: no referential-integrity check exists for personId (that check only ever runs against costCenterId columns) and no domain-membership check exists for it either (personId isn't a level/geo/org/cost-centre suffix and isn't declared as an enum), so nothing in the hard-check suite can ever confirm or refute this mapping — the schema check just needs some unique string, and any unique string would pass it. I approve it because employee_id is the column HRIS itself uses as the enterprise employee identifier, the join key that reconciles this export against payroll and against every downstream reference to a person. That's operational knowledge of how the source system is used, which lives outside the CSV and is exactly the kind of judgement a control total can never pin.

  • fte_pct → person.fte

    was blocking replay

    Decision: approve · Decided by: thomas.peng · Decided at: 2026-07-12T17:00:00Z

    fte_pct is numeric and takes only two values in this export (0.5, 1.0), sitting inside person.fte's declared [0,1] range — but the only hard check that ever sums a mapped numeric field against ground truth is control-total reconciliation, and checkControlTotals only ever sums approved_plan.approvedFte; it never inspects person records at all. A person.fte mapping therefore has zero hard-check coverage no matter what is mapped to it — type-plausibility only confirms 'this is a number', which a discount rate or a completion percentage would pass equally well. I approve it because fte_pct is HRIS's own fractional-headcount field, the exact number Finance already uses company-wide to answer 'how much of a head does this person represent' — that is operational knowledge of the source system, not something the ledger's own checks could ever derive.

ats

version bump: v1 → v2

  • req_id → req.reqId

    was blocking replay

    Decision: approve · Decided by: thomas.peng · Decided at: 2026-07-12T17:00:00Z

    req_id is unique across all 11 ats rows (REQ-5001 through REQ-7015) and follows a REQ-#### shape no other ats column shares. Exactly like a person identifier, there is no referential-integrity or domain-membership check that can ever touch a bare identifier column — the check suite only validates cost-centre joins and enumerable-domain membership, neither of which applies here. I approve it because req_id is the requisition number the ATS itself assigns, the value every downstream system (including HRIS once the req is filled) references by — that is a fact about how the ATS is operated, not something a schema or control total could ever pin.

anaplan

version bump: v1 → v2

  • Fiscal → approved_plan.fiscalPeriod

    was blocking replay

    Decision: approve · Decided by: thomas.peng · Decided at: 2026-07-12T17:00:00Z

    Fiscal reads 'FY26-Q3' on all three rows in this sample, and fiscalPeriod has no domain-membership check backing it — it isn't a level/geo/org/cost-centre suffix and it isn't declared as an enum in CANONICAL_FIELDS — so nothing in the hard-check suite ever validates its value regardless of how it's mapped; only the trivial type-plausibility check (is it a string) applies. I approve mapping Fiscal directly, rather than accepting the agent's implicit alternative of declaring it a constant, because Fiscal is a genuine per-row column in this source, not export metadata: a future Anaplan pull could legitimately span more than one fiscal period in a single export, and treating today's uniform value as a hardcoded constant would silently produce a wrong fiscalPeriod the day that happens. Anaplan explicitly reports this value per row for the plan it is submitting; that is the correct, durable mapping even though the current sample happens to be uniform, and it is a judgement about the shape of the export over time, not something any single-sample check could confirm.

sheet_a

No columns have been resolved by a human for this source yet — it replays on the agent’s own mapping alone.

sheet_b

No columns have been resolved by a human for this source yet — it replays on the agent’s own mapping alone.