Every capital program has at least one SharePoint workbook that someone treats as the real register. The AHJ-facing permit tracker. The inspection log the field team updates after walkdowns. The submittal matrix document control maintains for weekly coordination. The vendor promise list procurement references in standups.
Plathera holds the live program model: permits linked to packages, milestones, and conditions. SharePoint holds the version people edit in the meeting room. Both are "current" until someone tries to import rows on Sunday night before Monday's standup.
The hidden tax is familiar. Two registers drift every week. Someone runs VLOOKUP or copy-paste under deadline pressure. Rows slip through without a review packet leadership can defend. Leadership asks what changed. The PM rebuilds state from memory and three tabs.
Manual alignment works until volume, turnover, or schedule pressure breaks it. A permit tracker edited by three people with different column habits will not stay aligned with a structured database without enforced rules. Copy-paste imports hide ambiguous matches. Leadership sees updated counts without proof of what was matched, skipped, or flagged.
Generic chat tools make this worse, not better. A language model can summarize a spreadsheet. It cannot defend row alignment under EPC liability expectations without auditable matching rules, parse-quality gates, and an explicit write plan. Tabular reconciliation on capital programs needs a controlled workflow, not a conversational guess.
Plathera's EPC Assistant treats register reconciliation as a fixed chain. Each stage logs a receipt. The run stops plan-only after producing an HTML review artifact.
| Stage | What happens |
|---|---|
| Extract | Read the `.xlsx` workbook from SharePoint via Microsoft Graph using a sharing link. |
| Normalize | Apply a versioned mapping spec (for example `permits_v1`) for column aliases, dates, and numbers. |
| Load | Fetch candidate rows from the target table in the live program model by match key. |
| Match | Apply a named policy (for example `permit_revision_aware_v1`) with configurable tolerances. |
| Validate | Enforce parse-error limits and quality thresholds before any write plan is built. |
| Plan | Propose insert-only rows for unmatched entries; flag ambiguous matches for human review. |
| Report | Render a reconciliation review report as an HTML artifact for inspection. |
| Gate | Stop. No database write until a human confirms through the assistant. |
The assistant does not guess which spreadsheet row belongs to which permit record. It applies named mapping specs and match policies, then shows the result in a review packet a CM or document control lead can defend in standup.
Plan-only is not a limitation. It is the trust feature. EPC teams need proof of what would change before anyone clicks import. The write plan lists proposed inserts for unmatched rows and routes ambiguous matches to a requires-review queue. Low-quality parses fail the run instead of silently polluting the database.
Only after a human reviews the HTML artifact and confirms through the EPC Assistant does execution proceed. That confirmation gate aligns with how capital programs actually manage liability: show the evidence, name the exposure, then act.
The reconciliation review report groups rows into matched, unmatched, and ambiguous categories. Document control can fix the SharePoint workbook and re-run. A PM can approve deliberate inserts. A CM can walk into Monday standup with numbers tied to a defensible diff, not a hand reconciliation from Friday night.
Each stage in the chain leaves a receipt. When leadership asks how a permit count changed, the answer points to a review packet, not someone's memory of a paste operation.
A construction manager pastes the authority permit tracker link and asks:
Reconcile the Permits tab in this SharePoint workbook against our permits table and give me a review report before importing anything: [sharing link]The EPC Assistant returns an HTML reconciliation review report. Matched permit numbers appear with their program-model counterparts. Unmatched rows show what is missing from Plathera. Ambiguous rows wait for human judgment. Nothing writes to the database until confirmation.
The permit register is the documented example because every EPC program has one and the column chaos is universal. The same pipeline applies to other tabular registers: inspection logs, vendor promise lists, compliance matrices. Each register needs its own mapping spec and match policy. Plathera does not claim every table ships with a ready-made spec today. It claims the mechanism is repeatable once the mapping is defined.
The register in SharePoint is not wrong because people are careless. It is wrong because no one has a defensible diff against the live program model before the import button appears. Reconciliation should produce a review packet first, not a silent write.
Worth a conversation if your team still rebuilds register state before every review.
A workflow that reads a SharePoint register, matches rows against the live program model, and produces an HTML review report and write plan without changing the database until a human approves.
No. Reconciliation stops after the review report. Database writes require explicit human confirmation through the EPC Assistant.
The documented example is permit registers using the permits_v1 mapping spec. Other tabular registers can follow the same pipeline with new mapping specs.