I am a ChatGPT Plus user using ChatGPT/Work for substantial professional work involving taxation, electricity markets, power-sector analysis and regulatory assignments.
I am posting because I have seen several recent threads here describing individual aspects of a problem I am experiencing — long-context continuity failures, synthesis instead of verification, instructions being forgotten, and plausible but unverified statements being presented as facts.
My experience appears materially more severe because these failure modes are occurring together, repeatedly, even after I created explicit verification frameworks and blocking release gates specifically to prevent their recurrence.
The incidents include:
- Previously settled work being lost or reversed. A previously solved ₹4,797.85 income-tax dividend reconciliation was later treated as unresolved until I manually reminded ChatGPT of the earlier result. Settled F&O tax-treatment logic was also subsequently reopened or changed.
- Unverified inference being stated as fact in tax work. While reconciling a ₹40 Form 16/ITR discrepancy, ChatGPT first categorically attributed it to the standard deduction and then to Performance Linked Variable Pay. Both explanations were wrong. The actual cause was HRA entered as ₹6,08,044 instead of ₹6,08,004, which I ultimately identified myself. The source documents were already available.
- Repeated Excel/workbook failures despite an explicit hard-control framework. My continuing IeX electricity-derivatives project has a Master Context & Decisions Register, a seven-layer governance framework and an express blocking release gate. Nevertheless, a workbook represented as “FINAL”, “reopened”, “reconciled” and fully QA-passed had the principal 23-Aug Summary row blank, MTD formulas stopping at 22-Aug, and Excel displayed “[Repaired]” when the workbook was opened.
- QA showing PASS despite an objectively defective client-facing workbook. The raw data existed elsewhere, but the release tests did not verify the actual principal Summary cells. The precise defect that the controls were designed to prevent therefore passed the controls again.
- Repeated “final / verified / reconciled / all checks passed” representations when the saved artifact had demonstrably not passed those checks. For me this is more serious than an ordinary calculation error. It creates false confidence that the verification itself has been completed.
- Authoritative-source requirements being ignored or incompletely applied. In power-sector work I explicitly require CEA, Grid-India/NLDC, RLDCs, RPCs, NPP, exchange data, plant/state/region/national outages, coal, hydro, RE, transmission constraints and weather to be checked as relevant. The assistant has repeatedly reverted to narrower research despite those requirements already being settled.
- Market-price source controls being forgotten. For electricity derivatives I repeatedly required current official MCX/NSE evidence rather than stale workbook or third-party pricing. The same source-control issue has had to be corrected more than once.
- Workbook engineering failures. These have included formulas not extending through the latest date, numbers stored as text, stale formulas, wrong dependencies/linkages, redundant sheets and conceptual mixing of official DDR with diagnostic/continuity proxies.
- Other professional control failures. There have been source/image-identification errors in a power-sector project, failure to reproduce regulatory clauses verbatim despite an explicit drafting requirement, and repeated occasions where I had to tell the model to try alternative official retrieval routes rather than delegate unresolved retrieval back to me.
- An external-action verification failure. While assisting me in sending a complaint through my connected Gmail account, ChatGPT unnecessarily executed a test send to a random address before positively verifying the actual OpenAI Support recipient/thread. The assistant subsequently acknowledged that all exploration should have remained read-only until recipient, target and payload were verified.
- The AI-assisted OpenAI Support response itself made an apparently unverified account-specific assertion. It initially said that it could not see an active Plus subscription even though the same signed-in ChatGPT interface visibly showed Plus. I had to provide screenshot evidence and ask for authoritative account verification.
The cumulative consequence is that my weekly Work/Codex allowance has now reached 0%. A material amount of capacity has been spent repeating analyses, regenerating defective workbooks and rechecking work that had already been represented as verified.
What concerns me is not that AI sometimes makes mistakes. The concerning pattern is:
control established → model acknowledges control → control is supposedly run → output is represented as verified → objectively testable defect remains → user discovers it → rework consumes additional paid usage → same class of failure later recurs.
That is qualitatively different from an occasional hallucination.
Several recent Community threads appear to describe fragments of the same problem — especially plausible synthesis replacing verification and incomplete project-state reconstruction. My case suggests that stronger verification needs to be implemented as an actual blocking execution gate, particularly for high-consequence work and external write actions, rather than merely as a natural-language instruction that the model can subsequently bypass.
I have an escalated Support case open and have asked OpenAI to review both the reliability issue and restoration/credit of usage consumed through repeated defective rework.
I would be interested to know whether other heavy users working with long-running professional Projects/Work have experienced the same specific pattern: explicit verification controls being acknowledged but later bypassed while the output is nevertheless described as “verified” or “final”.