When the ISI workbook has more editors than it has controls

The workbook became software when nobody was looking

The ISI workbook usually begins as a personal tool. One engineer builds it, understands every formula, and uses it to prepare a schedule that is reviewed through the normal procedural route. It becomes a problem at the point where it stops being an aid and starts being the source. Once the outage schedule, the period completion status and the relief request basis are all derived from the same file, and once a second and third person are editing it between outages, the workbook is performing a quality-affecting calculation without any of the controls that would be required of software performing that calculation.

The specific gap is not hard to name. Appendix B expects documented instructions and procedures, control of the records that provide evidence of activities affecting quality, and controls appropriate to the activity. NQA-1 sets out expectations for software used in nuclear facility applications, including verification that it produces correct results, configuration control over changes, and identification of the version in use. A file with no revision history, shared write access, unlocked formulas and no test cases fails all three, and the failure is structural rather than a reflection on whoever maintains it.

Most sites discover this not through a self-assessment but through a discrepancy. A period status figure quoted in one document does not match the figure in another, and reconstructing which was right consumes an engineer for a week because both were produced by the same file at different times and the file no longer holds either state. That reconstruction cost, repeated, is usually what triggers the search for a real system.

Period credit is accounting, and accounting needs a ledger

Section XI Inspection Program B does not ask you to complete examinations by dates. It asks that, per examination category, a bounded fraction of the required examinations be credited within each period of the 120-month interval — a minimum of 16% and a maximum of 34% in the first period, 50% to 67% cumulative by the end of the second, and 100% by the end of the interval. Two things follow. Credit is counted against a population, so the population must be defined, versioned and auditable. And there is a ceiling as well as a floor, so doing too much in one period is a program error, not diligence.

Treating that as a ledger rather than a spreadsheet changes the data model. Each credited examination is a posting against a category, with a date, an outage, an examiner, a report reference and an approval. Percentages are derived from postings, never typed. Reversals — an examination credited and then found not to meet the requirement — are entered as reversing postings rather than by deleting a row, so the history of the calculation survives. This is ordinary double-entry discipline applied to code credit, and it eliminates the entire class of errors caused by editing.

The population question deserves separate attention when a risk-informed program is in place. Adopting a risk-informed inservice inspection program under an approved Code Case changes which welds are in scope and therefore changes the denominator of every affected percentage. A workbook typically absorbs that change by overwriting a column. A ledger handles it as a versioned population with an effective date, so credit taken before the change is still computed against the population that was in force at the time — which is exactly the question an inspector asks.

Deferral rules live at the item level, not at the plant level

Section XI permits certain examinations to be deferred to the end of the interval, and the permission is granted per item in the examination category tables, not as a general allowance. It exists because some components can only be examined in specific plant conditions that do not occur every outage. Operationally, the deferral flag is one of the most valuable pieces of data in the whole program, because it determines how much freedom the schedule has and how much load is being pushed toward the last refueling outage of the interval.

It is also the piece of data most likely to be lost. Deferral status typically lives as a column of Y and N values that is carried forward by copying rows between annual versions of the workbook. A sort applied to one column but not the whole range, a paste that lands one row off, or a filtered copy that excludes hidden rows will all corrupt it silently, and the corruption only becomes visible in Period 3 when the deferred population turns out to be larger or smaller than planned. By then the outage in which the exam should have been taken is two years gone.

In a proper system the deferral permission is an attribute of the code item, inherited by every examination generated from it, and it cannot be edited on the individual examination without an authorization that is recorded. The schedule can then answer the question that actually matters mid-interval: what is the deferred backlog, what plant conditions does each deferred item require, and does the final outage of the interval have enough qualified crew, access and dose margin to absorb it. That question is unanswerable from a workbook until it is too late to act on.

Qualified crews are not interchangeable

Outside nuclear, crew scheduling is largely a question of method and level: find an available Level II in ultrasonics. Inside nuclear, ultrasonic examination of most Section XI scope is qualified as a system under Appendix VIII, demonstrated through the industry performance demonstration program, and the qualification attaches to a combination of procedure, equipment and personnel for a specific component configuration and flaw orientation. A technician qualified for austenitic piping welds is not qualified for the reactor pressure vessel, for cast austenitic stainless steel, or for dissimilar metal welds simply by virtue of holding a level.

The scheduling consequence is that assignment is a constraint satisfaction problem, not a lookup. The system needs to hold, for each examination, the required qualification set; for each person, the demonstrations they currently hold with expiry dates; for each procedure, its qualification status and revision; and for each equipment set, its qualification and calibration status. Assignment succeeds only when all four match at the planned date. Any module that models qualification as a single field on the employee record will produce a schedule that collapses in the outage control center.

This constraint has a second-order effect on the calendar. Because the qualified population for some scope is small and shared across the fleet and the vendor market, the availability of a specific qualified crew during a specific outage window is frequently the binding constraint on when an examination can occur — ahead of code windows, ahead of access, ahead of everything else. Schedules built without visibility of that availability tend to be optimistic by exactly the amount of time it takes to discover the crew is committed elsewhere.

Dose is a scheduling resource with a hard budget

An outage carries a person-rem budget built up from job-level estimates, tracked against occupational limits in 10 CFR 20 and against the site's ALARA commitments. Every examination in a radiation area draws on it, and the draw varies enormously with location, dose rate, the time required, and the preparatory work — scaffolding, insulation removal, decontamination — that has to happen in the same field. Two examinations that look identical on a code schedule can differ by a factor of several in what they cost the outage.

This makes dose a scheduling dimension in the same sense that crew hours and access windows are. When an examination can legitimately be taken in either of two outages, dose rate is often the deciding factor, because source term differs with time since shutdown and with chemistry decontamination performed in a given outage. When two examinations compete for the same window, sequencing them so one crew's shielding and scaffold serves both may halve the total dose. None of these decisions can be made from a schedule that does not carry a dose estimate per task.

The practical requirement is modest and specific: each examination carries a planned collective dose, a basis for that estimate, and an actual recorded afterward; the outage aggregates them; and the planner can see the running total against budget as scope is added or moved. The value shows up in the second year, when the estimates have been calibrated against actuals and the planning numbers stop being guesses. That feedback loop is impossible in a workbook that is rebuilt from scratch each cycle.

Reproducing a due date as of a past date

The question an inspector or an assessor asks is rarely what the schedule says now. It is why a particular examination was moved, deferred or credited in a prior outage, and what the program looked like at the moment the decision was taken. Answering it requires the system to reconstruct a past state: the population in force then, the credits posted up to that date, the Code edition governing the interval, the qualification status of the people involved, and the approval that authorized the action. A workbook holds only its current state and therefore cannot answer at all.

Building for reproducibility is mostly a matter of refusing to overwrite. Rules get effective dates rather than being edited in place. Credits are postings with timestamps, reversed rather than deleted. Approvals are records naming a person, a basis and a date, attached to the thing they authorize. Populations are versioned. With that structure, an as-of query is straightforward and the answer is defensible because it is assembled from primary records rather than from someone's reconstruction.

There is a related discipline worth adopting at the same time. Every automated calculation the system performs — period percentage, remaining population, next required examination — should be exercised by a stored set of test cases with known expected results, re-run whenever the calculation changes, with the results retained. That is the verification evidence the software controls expect, and it is also the fastest way to detect that a configuration change has quietly altered a number that hundreds of decisions depend on.

Getting off the workbook without importing its errors

The temptation during migration is to load the workbook as-is and correct later. Do not. The workbook's defects are exactly the defects the new system is meant to eliminate, and once loaded they acquire the authority of the new system without ever having been examined. The better sequence is to rebuild the population from primary sources — the Code tables, the plant's isometric and weld data, the approved program document — and then reconcile the workbook against that rebuilt population as an independent check.

That reconciliation is where the value is. Typical findings include examinations in the workbook that no longer exist in the plant, welds in the population that appear in no workbook row, credits posted against the wrong category, deferral flags that disagree with the Code item, and a small set of examinations whose completion evidence cannot be located. Each of these is a real program finding that the workbook was concealing rather than creating. Documenting them, with dispositions, is a stronger position going into an assessment than a clean-looking import would have been.

Atlantis configures inspection scheduling on an Odoo ERP foundation for nuclear and heavy-industrial inspection organizations, with versioned populations, posting-based credit, qualification matching at assignment, dose budgeting and as-of reconstruction as native structures. It is affordable, accessible and fully customizable, and we prefer to begin with a reconciliation of your existing workbook against a rebuilt population so you can see what it is currently hiding. To arrange a working session, contact info@atlantisndt.com.

Request a consultation