MXH · Method
Every finding says how well it is evidenced — and what that evidence does not let us claim.
Severity and evidence are different questions. A difference that will stop your system booting may rest on a single dictionary observation; a difference IBM's own upgrade script states outright may be harmless. MXH grades both, separately, on every row.
How MXH works, in eight steps
- You export your configuration. Run it yourself and nothing leaves your network. MXH reads an export: your dictionary, your code and your screens. It needs no live Maximo and makes no network call. What you didn't send is declared in the manifest, and the report says so.
- Against IBM's own releases, not our opinion of them. One metadata pack per release, read from what IBM ships: upgrade scripts, dictionary, domains, relationships, screens, configuration and the compiled API. The API facts are re-checked against IBM's registry: 12,651 classes and 79,377 members at 9.2, no difference.
- Six comparisons, run at once. Each comparison yields its own evidence class, from IBM's upgrade scripts (A1) to a dictionary-only difference (B2) and modelled behaviour (C). An attribute dropped and re-added is a redefinition, and a method moved to a parent class is still reachable. Neither is reported.
- Your code decides what matters. Only the changes your objects, code and screens touch come through. In the sample, PermitGate.java:8 references psdi.iface.jms.ErrorQueueNotfCronTask, which IBM's API at 9.1 doesn't have. That's BLOCKING.
- Two grades on every finding. Severity says how much it hurts. Evidence class says how sure we are. A removed member in a class your code references stays REVIEW until a call is established.
- Every finding has an owner, an action and a closure test. The sample's 99 findings: 1 BLOCKING, 90 REVIEW, 8 ENVIRONMENT, from 4 assessed objects and 3 scanned source files, 7.6.1.3 → 9.2.
- Same inputs, same report, byte for byte. Every input is hashed into a lock file with the pack digests and a run ID. Run it again on the same inputs and you get the same ID and the same 7 files.
- Fix, rerun, prove it closed. A rerun sorts every finding into one of 7 outcomes. Missing input is never counted as a fix. The sample stands at static analysis on the proof ladder. Your list arrives 5 business days after your export does.
How far a fix is proven
- Static analysis: the sample is here
- Harness run: outstanding
- Target compile/link: outstanding
- Target runtime: outstanding
- Business acceptance: outstanding
A ticket marked done is not verification. Accepted risk is not a fix.
One finding, two separate questions
Every finding answers two questions. Its grade says how much it hurts. Its evidence class says what the evidence behind it is, and what that evidence lets us state. One doesn't set the other.
REVIEW · evidence class A2
"psdi.app.person.Person.getAvailableHours(Ljava/util/Date;Lpsdi/app/person/PersonCalRemote;Lpsdi/app/common/AvailCalc;)D is gone in 8.7; you reference the class — check the call"
Grade: REVIEW. The class is still there but this method isn't, so it breaks only if your code calls it, and checking the call settles that. Evidence class: A2, bytecode/api confirmed. State that the type or member is gone at the target release.
The sample's one BLOCKING finding, psdi.iface.jms.ErrorQueueNotfCronTask, is evidence class A2 too: the same class, a different grade.
The six evidence classes, plainest first
| Class | What it lets us state | What it does not prove |
|---|---|---|
| A1 IBM or the target said so | State it as what the release does, and name the script. | Do not state it as an outcome without checking the target dictionary agrees. |
| A2 IBM or the target said so | State that the type or member is gone at the target release. | Do not call it gone without checking the target's own inheritance first. |
| A3 IBM or the target said so | State that the target does not accept it, and name the registry. | Do not generalise from one registry to the product. |
| B1 We worked it out | State it as a release change, naming both the dictionary difference and the corroborating script. | Do not claim the script's specific values. |
| B2 We worked it out | Say "between these two dictionaries", and say which two. | Never state it as a release change, and never as something IBM did. |
| C We worked it out | Attribute it to the model and link the rule's evidence and its assumptions. | Do not present it as measured, and do not imply coverage. |
In short: A-classes come from IBM's own scripts or a compiled build, so we say them plainly. B and C classes come from comparing two systems, which can differ for reasons that have nothing to do with the new release — so we say what we found, not more than that.
The sample, by grade and evidence class
Severity and evidence are separate axes: how much it hurts ≠ how sure we are.
| Grade | A1 | A2 | A3 | B1 | B2 | C |
|---|---|---|---|---|---|---|
| BLOCKING | 0 | 1 | 0 | 0 | 0 | 0 |
| REVIEW | 10 | 3 | 1 | 12 | 64 | 0 |
| ENVIRONMENT | 0 | 0 | 0 | 0 | 8 | 0 |
Run it twice, get the same answer
Every run is logged: every input, every score, a fingerprint of the exact build used. Run it again on the same inputs and you get byte-for-byte the same report. That is what lets a client's own team check our work instead of taking it on faith.
