Agent trace
Evidence is computed from checks that ran against a candidate mapping — it is never self-reported by the model. A hard check (solid, colored) is real ground truth: failing one means the mapping IS wrong. A heuristic check (dashed, muted) is plausibility only: passing one means nothing, and never promotes a column to hard evidence on its own.
hris
NOT REPLAYABLE — a required field is left uncovered by escalation
This is the correct, honest outcome, not a bug: at least one escalated column was the only candidate for a required canonical field, so applyMapping cannot produce ledger records from this artifact until a human resolves the escalation(s) below.
entity "person" is missing required field "personId" (person.personId): it was neither mapped by an active mapping entry nor supplied by a declared constant. An artifact that cannot cover its required fields is not replayable — resolve this mapping before freezing it.
Final mapping
| Source column | Canonical field | Evidence | Escalated |
|---|---|---|---|
| employee_id | person.personId | heuristic only | yes — needs a human |
| cost_center | person.costCenterId | hard evidence | no |
| job_level | person.level | hard evidence | no |
| location | person.geo | hard evidence | no |
| fte_pct | person.fte | heuristic only | yes — needs a human |
| start_date | person.validFrom | heuristic only | yes — needs a human |
| employment_type | person.employmentType | hard evidence | no |
Hypotheses (1)
iteration 0 — accepted
Hard checks — ground truth
- schema PASS— all rows parse
- referential-integrity [cost_center] PASS— all cost centres join
- control-total PASS— approved FTE reconciles against known totals
- domain-membership [cost_center] PASS— all values are members of the known domain
- domain-membership [job_level] PASS— all values are members of the known domain
- domain-membership [location] PASS— all values are members of the known domain
- domain-membership [employment_type] PASS— all values are members of the known domain
Heuristic checks — plausibility only
- type-plausibility [employee_id] PASS— string is plausible for string
- type-plausibility [cost_center] PASS— string is plausible for string
- type-plausibility [job_level] PASS— string is plausible for string
- type-plausibility [location] PASS— string is plausible for string
- type-plausibility [fte_pct] PASS— number is plausible for number
- type-plausibility [start_date] PASS— date is plausible for date
- type-plausibility [employment_type] PASS— string is plausible for enum
- enum-cardinality [employment_type] PASS— cardinality 1 vs 4 allowed values
Escalations (3)
- employee_id → person.personId
Cardinality equals total row count (254/254), a per-row unique identifier string — the natural key for person. — escalated: only heuristic evidence supports this mapping
- fte_pct → person.fte
Numeric, bounded 0.5-1.0, matches person.fte's expected fractional full-time-equivalent range. — escalated: only heuristic evidence supports this mapping
- start_date → person.validFrom
Genuinely per-row date (240 distinct values across 254 rows), not a uniform export timestamp — this is the employee's own valid-from date, which person.validFrom is meant to capture as a real per-row fact. — escalated: only heuristic evidence supports this mapping
ats
NOT REPLAYABLE — a required field is left uncovered by escalation
This is the correct, honest outcome, not a bug: at least one escalated column was the only candidate for a required canonical field, so applyMapping cannot produce ledger records from this artifact until a human resolves the escalation(s) below.
entity "req" is missing required field "reqId" (req.reqId): it was neither mapped by an active mapping entry nor supplied by a declared constant. An artifact that cannot cover its required fields is not replayable — resolve this mapping before freezing it.
Final mapping
| Source column | Canonical field | Evidence | Escalated |
|---|---|---|---|
| req_id | req.reqId | heuristic only | yes — needs a human |
| status | req.state | hard evidence | no |
| team | req.orgId | hard evidence | no |
| level | req.level | hard evidence | no |
| accepted_on | (no canonical home) | none | yes — needs a human |
| expected_start | req.expectedStart | heuristic only | yes — needs a human |
Hypotheses (1)
iteration 0 — accepted
Hard checks — ground truth
- schema PASS— all rows parse
- control-total PASS— approved FTE reconciles against known totals
- domain-membership [status] PASS— all values are members of the known domain
- domain-membership [team] PASS— all values are members of the known domain
- domain-membership [level] PASS— all values are members of the known domain
Heuristic checks — plausibility only
- type-plausibility [req_id] PASS— string is plausible for string
- type-plausibility [status] PASS— string is plausible for enum
- enum-cardinality [status] PASS— cardinality 5 vs 5 allowed values
- type-plausibility [team] PASS— string is plausible for string
- type-plausibility [level] PASS— string is plausible for string
- type-plausibility [expected_start] PASS— date is plausible for date
Escalations (3)
- req_id → req.reqId
Cardinality 11 == total 11 (unique per row), values 'REQ-5001' etc. are the natural requisition identifier. — escalated: only heuristic evidence supports this mapping
- accepted_on → (no canonical home)
Represents the date an offer was accepted, but there is no req.acceptedDate (or equivalent) in the canonical schema — only req.expectedStart exists, which is a distinct concept (planned start date, not acceptance date). Forcing this onto expectedStart would conflate two different dates, so it is left unmapped.
- expected_start → req.expectedStart
Per-row date values matching the name and semantics of req.expectedStart (planned start date for the role). — escalated: only heuristic evidence supports this mapping
anaplan
NOT REPLAYABLE — a required field is left uncovered by escalation
This is the correct, honest outcome, not a bug: at least one escalated column was the only candidate for a required canonical field, so applyMapping cannot produce ledger records from this artifact until a human resolves the escalation(s) below.
entity "approved_plan" is missing required field "fiscalPeriod" (approved_plan.fiscalPeriod): it was neither mapped by an active mapping entry nor supplied by a declared constant. An artifact that cannot cover its required fields is not replayable — resolve this mapping before freezing it.
Final mapping
| Source column | Canonical field | Evidence | Escalated |
|---|---|---|---|
| CC | approved_plan.costCenterId | hard evidence | no |
| Org | approved_plan.orgId | hard evidence | no |
| Fiscal | approved_plan.fiscalPeriod | heuristic only | yes — needs a human |
| Hdct | approved_plan.requestedFte | heuristic only | yes — needs a human |
| Approved FTE | approved_plan.approvedFte | hard evidence | no |
| Contractors Incl | (no canonical home) | none | yes — needs a human |
Hypotheses (1)
iteration 0 — accepted
Hard checks — ground truth
- schema PASS— all rows parse
- referential-integrity [CC] PASS— all cost centres join
- control-total PASS— approved FTE reconciles against known totals
- domain-membership [CC] PASS— all values are members of the known domain
- domain-membership [Org] PASS— all values are members of the known domain
Heuristic checks — plausibility only
- type-plausibility [CC] PASS— string is plausible for string
- type-plausibility [Org] PASS— string is plausible for string
- type-plausibility [Fiscal] PASS— string is plausible for string
- type-plausibility [Hdct] PASS— number is plausible for number
- type-plausibility [Approved FTE] PASS— number is plausible for number
Escalations (3)
- Fiscal → approved_plan.fiscalPeriod
Value 'FY26-Q3' is a fiscal-period label. Even though it's uniform across this 3-row sample, the column genuinely carries the value per row, so it's mapped as a normal column entry rather than declared as a constant. — escalated: only heuristic evidence supports this mapping
- Hdct → approved_plan.requestedFte
Numeric headcount values (49, 95, 128) that are consistently higher than the paired 'Approved FTE' values for the same rows — consistent with a requested/asked-for headcount figure prior to approval, matching the optional requestedFte field. — escalated: only heuristic evidence supports this mapping
- Contractors Incl → (no canonical home)
A 'Y' flag indicating whether contractor headcount is included in the plan figures. No canonical field represents this boolean qualifier for approved_plan; there's no place in the schema to put it, so it's left unmapped rather than forced onto an unrelated field.
sheet_a
replayable — applyMapping succeeds against this artifact
Final mapping
| Source column | Canonical field | Evidence | Escalated |
|---|---|---|---|
| Team | approved_plan.orgId | hard evidence | no |
| CC | approved_plan.costCenterId | hard evidence | no |
| Hdct | approved_plan.approvedFte | hard evidence | no |
| Q3 Ask (fte) | approved_plan.requestedFte | heuristic only | yes — needs a human |
| Lvl | (no canonical home) | none | yes — needs a human |
| Loc | (no canonical home) | none | yes — needs a human |
| Updated | (no canonical home) | none | yes — needs a human |
Hypotheses (1)
iteration 0 — accepted
Hard checks — ground truth
- schema PASS— all rows parse
- referential-integrity [CC] PASS— all cost centres join
- control-total PASS— approved FTE reconciles against known totals
- domain-membership [Team] PASS— all values are members of the known domain
- domain-membership [CC] PASS— all values are members of the known domain
Heuristic checks — plausibility only
- type-plausibility [Team] PASS— string is plausible for string
- type-plausibility [CC] PASS— string is plausible for string
- type-plausibility [Hdct] PASS— number is plausible for number
- type-plausibility [Q3 Ask (fte)] PASS— number is plausible for number
Escalations (4)
- Q3 Ask (fte) → approved_plan.requestedFte
Explicitly labeled as an 'ask' in fte units — the requested (not yet approved) fte for the period, matching requestedFte. — escalated: only heuristic evidence supports this mapping
- Lvl → (no canonical home)
Values like IC4/IC3/IC2 are a person/req level, but approved_plan has no level field in the canonical schema — no counterpart to map to.
- Loc → (no canonical home)
Location codes (US-SF, IE-DUB, PH-MNL) would fit a geo field, but approved_plan has no geo field in the canonical schema — no counterpart to map to.
- Updated → (no canonical home)
Single constant date (cardinality 1) is an export-freshness/as-of stamp, not a per-row canonical value; validFrom/validTo are ingest metadata supplied by the caller, not something this proposal declares.
sheet_b
replayable — applyMapping succeeds against this artifact
Final mapping
| Source column | Canonical field | Evidence | Escalated |
|---|---|---|---|
| Group | approved_plan.orgId | hard evidence | no |
| CostCtr | approved_plan.costCenterId | hard evidence | no |
| Heads | approved_plan.approvedFte | hard evidence | no |
| Band | (no canonical home) | none | yes — needs a human |
| Site | (no canonical home) | none | yes — needs a human |
| AsOf | (no canonical home) | none | yes — needs a human |
Hypotheses (1)
iteration 0 — accepted
Hard checks — ground truth
- schema PASS— all rows parse
- referential-integrity [CostCtr] PASS— all cost centres join
- control-total PASS— approved FTE reconciles against known totals
- domain-membership [Group] PASS— all values are members of the known domain
- domain-membership [CostCtr] PASS— all values are members of the known domain
Heuristic checks — plausibility only
- type-plausibility [Group] PASS— string is plausible for string
- type-plausibility [CostCtr] PASS— string is plausible for string
- type-plausibility [Heads] PASS— number is plausible for number
Escalations (3)
- Band → (no canonical home)
Values (IC4, IC5, IC3, IC2, IC1) are job-level codes, but approved_plan has no level field in the canonical schema — there is no counterpart to map this to.
- Site → (no canonical home)
Values (US-SF, IE-DUB, IN-BLR, PH-MNL) are geo/location codes, but approved_plan has no geo field in the canonical schema — there is no counterpart to map this to.
- AsOf → (no canonical home)
Low-cardinality (2) date column reading as an export/as-of snapshot stamp rather than a per-row fact the plan carries — this is ingest metadata (recordedAt-equivalent) the caller supplies itself, not a value this proposal should map.