Every number in the audit workbooks was recomputed from its own detail rows, and the two Python builders that produced the newest file were read line by line. The scope covers the current actively-rebuilt import first, then the wider corpus, then the test for intentional manipulation.
Update, 2026-07-28. The remediation is tracked at question-audit-closeout: one canonical 122-row timed file, ten of the fourteen defects below closed, and the provenance limit that still applies to any per-coach comparison.
The minute-by-minute arithmetic is right. Answered-minus-asked equals the stated resolution time on every row of the current file, and the workbook that includes live reconciliation formulas passes all thirteen of its own checks. The damage is one level up, in how the newest file was merged. The active import stitches the original client rows to a batch of hand-read rows without normalizing them, so one timing column holds text in 24 rows and numbers in 29, times appear in two different clock formats, the two slowest resolutions have no status label, and a missing date silently defaults to July 21. The build script visibly tries to be honest, it refuses to fake an acknowledgment time and leaves it blank instead. That is the signal that this is a merge-quality failure. Fraud would leave different traces. The one line that crosses into guessed-data territory is the default date. If this file reaches a Power BI dashboard in its current shape, the mixed-type column alone will misreport timing.
~/Downloads/QuestionAudit_PowerBI_Import_ALL_7-22.xlsx
Written 2026-07-23 at 11:59, 53 rows, produced by rebuild_original_schema.py.
This is the newest workbook in the corpus and the one the current worklist is trying to get right.
The seven items below are the recent errors.
The raw resolution math is correct. Recomputing answered-time minus asked-time for all 53 rows produced zero mismatches against the stated ResMin. Everything flagged below is a merge, type, or labeling defect, and each one is the kind of thing that makes a downstream dashboard wrong even when every cell still looks plausible.
| # | Defect | Evidence in the file | Why it matters |
|---|---|---|---|
| 1 | Timing column mixes text and numbers | ResMin is text in 24 rows, a number in 29 | Power BI coerces a mixed column, which silently zeroes or drops timing. This is the most likely cause of a wrong dashboard. |
| 2 | Acknowledgment metric covers 45% of rows | AckMin and AckStatus blank on 29 of 53 | Any average acknowledgment time runs on 24 rows and ignores the rest. The blank is honest. The silent denominator that results is the real problem. |
| 3 | The two slowest rows have no status | r36 (25 min) and r42 (26 min) have blank ResStatus | A status rollup undercounts escalations by leaving out the two worst cases. |
| 4 | Missing date defaults to July 21 | Unmatched rows written as 2026-07-21 | A guessed date presented as real. 27 of 53 rows show 7/21, an unknown share of them by default. |
| 5 | Two clock formats in one column | 24 rows read 13:09, 29 read 1:09 PM | Any time parser expecting one format mishandles the other half of the file. |
| 6 | Status boundary mislabel | r54 at 10 min tagged Escalate | The stated guide puts 10 minutes in Watch. Escalate is over 10. One-row off-by-one. |
| 7 | Filename does not match contents | labeled 7-22; rows are 7/21×27, 7/22×11, 7/23×15 | The file is mostly not 7/22, and the name leaves out the 7/23 day. |
Per-responder counts in this file: Toveta 19, Tami 13, Margarita 8, Raushanah 8, Fabian 5, totaling 53. That makes at least six different counts for Toveta across the corpus (17, 19, 21, 23, and 4).
Two builders write to this same path. Reading them shows the defects are byproducts of a good-faith merge. None is a choice to mislead.
The single most important number in a performance audit is how many interactions it covers. This corpus states that number at least eight ways and never declares which is true.
| Stated as | Count | Where | What it actually is |
|---|---|---|---|
| Video items | 22 | Video_Frames | 12 frames, 11 answered |
| Answered records | 26 | Client_July21 / WorldClass | ranking underneath sums to 24 |
| Answered records | 37 | WorldClass_Updated | ranking sums to 34, a 6th coach appears |
| Screenshot rows | 50 | FROM_SCREENSHOTS | hand-verified core |
| Current import rows | 53 | PowerBI_Import_ALL (11:59) | 25 CSV + 28 hand-read, mixed shape |
| Classified rows | 63 | ROWLEVEL / PowerBI-63 | 61 coaching + 2 admin |
| Interactions | 69 | FULL | 67 coaching + 2 admin |
| Master rows | 318 | MASTER | 50 verified + 268 OCR, 72 usable |
Each is defensible as a specific cut. The failure is that they travel under one project name with no map from one to the next, so any reader picks a number and is wrong for some other reader's purpose.
These files rank coaches by name, and the ranking is not stable. The number-one seat moves between two CONFIDENTIAL client versions, and every coach's question count changes from file to file.
| Coach | Client Jul-21 | Exec Updated | ROWLEVEL | FULL Scorecard | Current 11:59 | MASTER |
|---|---|---|---|---|---|---|
| Fabian Andres Sierra | 2 · #1 | 3 · #3 | 6 | 6 | 5 | 9 |
| Toveta Jenkins | 6 · #2 | 12 · #1 | 21 | 17 | 19 | 4 |
| Tami Bales | 7 · #3 | 7 · #2 | 15 | 12 | 13 | 20 |
| Margarita Rosa Del Valle | 4 · #4 | 5 · #4 | 12 | 9 | 8 | 35 |
| Raushanah Muro | 5 · #5 | 6 · #5 | 9 | 7 | 8 | 11 |
| Yonny Saldarriaga | n/a | 1 · #6 | n/a | n/a | n/a | 1 |
| Total | 24 (hdr 26) | 34 (hdr 37) | 63 | 51 | 53 | 318 |
Fabian is ranked number one on two cases in the client version, and the file's own footnote concedes it: "Fabian tops the table on 2 cases by a fraction of a point, so his rank is the fragile one." The headline still prints him at rank one. In the next version he drops to three and Toveta takes the top on twelve. In the master file Toveta collapses to 4 and Margarita jumps to 35, because that file is OCR-driven and left 236 of 318 coach names as (not captured). A reader of the master would conclude Margarita is the busiest coach. A reader of ROWLEVEL would conclude Toveta is.
Sorted by severity. The recent merge defects are Tier 1 and Tier 2. Arithmetic is the smallest tier.
Text and number in one column is the defect most likely to make a Power BI report wrong. It is item 1 above.
The 25 and 26 minute resolutions have no status, so an Escalate count misses them. Item 3 above.
Number one moves from Fabian to Toveta between two client Executive Summaries, and a coach is ranked one on two data points.
Twenty-six then thirty-seven reach a client. Internal files record 53, 63, and 67, and the OCR master records 318. No document states the real figure or supersedes the others.
A missing date resolves to July 21 rather than staying blank. Item 4 above, the one place the recent code writes a value it does not know.
"Total rows: 318 (50 hand-verified + 268 video-only). Dashboard showed 5." That frames 318 against 5. By the file's own rules the defensible figure is 254 after removing flagged duplicates, 100 with any answer seen, or 50 hand-verified.
The master's Day column reads Wed 268, Yesterday 38, Tuesday 7, Today 4, "7/22/2026" 1. "Today" and "Yesterday" are wrong the next morning.
The current import carries 24-hour and 12-hour times, and a 12-column shape stitched to rows that were built for a 25-column shape. Items 5 and 2 above.
Master and ROWLEVEL share only four category names. "Coach Stamp / OSHA" in one is "Coach Stamp / OSHA 500" in the other, so counts do not join across files.
ROWLEVEL flags one duplicate and excludes it. The master flags 64 probable OCR duplicates and counts every one inside the 318.
Four of five coaches recompute to the row. Toveta was computed on 17 of her 18 timed interactions. The dropped row was about one minute, which pushed her average answer time from 9.06 to 9.53 and her sub-5-minute rate from 0.667 to 0.647. The slip runs against the coach.
It sums to 51. The same workbook's header says 67 and its By Day tab sums to 67. The Scorecard switched to a timed-only denominator with no note.
Shown for balance. All 53 answered-minus-asked values match. The raw calculator works. The failures are type, schema, and labeling.
Row counts run 6, 9, 22, 42, 43, 45, 50, 52, 53, 63, 309, and 318. Names differ only by suffix: _Updated, _Corrected, _WorldClass, _With_New_Chats, (1). Several will not open. Nothing marks one as current.
ROWLEVEL is the workbook that promises the most: "every total equals the included row count," with live Excel tamper-check formulas beside every static value. Tested against its own 63 rows, all thirteen reconciliation checks passed, and so did the full category-by-coach grid, the coach totals, every timing average, and the daily volume.
| Reconciliation check | Stated | Recomputed | Verdict |
|---|---|---|---|
| Row count in classified table | 63 | 63 | PASS |
| Sum of category totals equals rows | 63 | 63 | PASS |
| Sum of coach totals equals rows | 63 | 63 | PASS |
| Category × coach grid grand total | 63 | 63 | PASS |
| Rows with blank answer text | 21 | 21 | PASS |
| Rows with no answer time | 11 | 11 | PASS |
| Timing denominator (answer-time present) | 52 | 52 | PASS |
| Coaching-scope view | 61 | 61 | PASS |
| Unique-coaching view | 60 | 60 | PASS |
| Administrative rows | 2 | 2 | PASS |
| Duplicate rows | 1 | 1 | PASS |
| Pending-review rows | 2 | 2 | PASS |
| Countable (answered, coaching, non-dup) | 52 | 52 | PASS |
The category grid recomputed with zero mismatches across all 65 populated cells, and every per-category timing average matched to one decimal. This is the control for the whole evaluation. It shows the tooling can produce a workbook that reconciles perfectly, so the failures elsewhere are choices about method and merge. The calculator itself works.
The master breakdowns all foot to 318. Source, confidence, coach, category, and date each sum correctly. The problem is what the 318 is made of.
Ninety-three percent of the file ends up in one category, so the category field carries almost no information, and that pile-up traces directly to the catch-all default in merge_723_final.py. Seventy-four percent has no coach. The honest usable core is 72 rows. The workbook prints 318 as the headline and buries the "filter out duplicates and unverified rows before a final count" instruction in a note at the bottom.
Forensic accounting looks for specific fingerprints of intentional manipulation. Each was checked against the corpus and the build scripts.
| Signature of manipulation | Present | What the evidence shows |
|---|---|---|
| Totals that do not foot to their parts | NO | Every breakdown sums correctly: 318, 63, 69, 53, 22 |
| A formula overwritten with a hardcoded value | NO | ROWLEVEL static values equal their live COUNTIF, side by side |
| Errors biased one direction to favor a party | MIXED | The Toveta slip and the blank worst-row status both cut against accuracy and favor no one |
| Data invented where it was unknown | ONE CASE | The default July 21 date. Elsewhere the code leaves blanks rather than fake |
| Round-number overrides | NO | None found |
| Undisclosed denominator switching | PARTIAL | Scorecard 51 vs 67, "318 vs 5", 26 then 37 |
| Confident claims beyond the evidence | YES | "World-class" client rankings on n=2, unstable number one |
Not established. There is no cooked sum, no lie pasted over a formula, and no error bent to favor any individual. The recent build script actively refuses to fabricate, it leaves acknowledgment times blank rather than invent them. The conduct a reviewer would still flag is twofold. First, presentation: packaging unstable, undersized, non-reconciling counts as CONFIDENTIAL and world-class, and leading a master file with a 318-against-5 comparison the data does not support. Second, one concrete data-invention line: the default July 21 date. Both are recoverable process failures. This becomes malfeasance only if someone knew the counts were provisional and shipped them as settled anyway. The files prove the numbers were not ready to be presented the way they were. They do not prove intent.
A fair evaluation credits the parts done well, because they set the standard the rest should meet.
Recompute scripts, run against the workbooks below, live in the session scratchpad (recompute_current.py, recompute.py, recompute2.py, recompute3.py, verify_expansive.py). Build scripts read in full: rebuild_original_schema.py, merge_723_final.py.
| File | Rows | Note |
|---|---|---|
| ~/Downloads/QuestionAudit_PowerBI_Import_ALL_7-22.xlsx | 53 | current, 11:59, defects 1 through 7 |
| ~/Projects/_outputs/audit/Question_Response_Classification_ROWLEVEL_2026-07-22.xlsx | 63 | canonical candidate, reconciles 13/13 |
| ~/Projects/_outputs/audit/QuestionAudit_PowerBI_Import_2026-07-22.xlsx | 63 | matches ROWLEVEL |
| ~/Projects/_outputs/audit/Question_Response_Audit_FULL_2026-07-22.xlsx | 69 | E11, E12 live here |
| ~/Projects/_outputs/audit/Video_Frames_FULL_Extraction.xlsx | 22 | clean |
| ~/Downloads/QuestionAudit_MASTER_7-22_ALL.xlsx | 318 | E6, E7, E9, E10 live here |
| ~/Downloads/Question_Response_Audit_WorldClass.xlsx / Client_July21.xlsx | 26 | client Exec, ranks Fabian #1 on n=2 |
| ~/Downloads/Question_Response_Audit_WorldClass_Updated.xlsx | 37 | ranks Toveta #1, adds a 6th coach |
Row counts observed across the full corpus: 6, 9, 22, 42, 43, 45, 50, 52, 53, 63, 309, 318, spread over roughly forty workbooks and their duplicate copies.