MXH · Assessment

Send an export of your Maximo. Get back every place it disagrees with the release you are moving to.

An MXH assessment is one command over one directory. The directory declares what you run today, what you are moving to, and — just as importantly — what you did not send. Everything in the report traces back to something in it.

What you send

One folder, described by a manifest, so the folder is the unit: zip it, send it, and it reads the same inputs anywhere.

• Your data dictionary — the object, attribute, relationship and synonym-domain tables, as CSV or JSON. A REST fetcher ships with the product, so you can pull it over the API instead of running a database export.
• Your customisation source — Java, automation scripts, or both.
• Your Application Designer screens — the presentation XML exports.
• Your declarations — the release you are on, the industry solutions installed, the date of the export, and anything you are holding back, with the reason.

An incomplete or self-contradictory manifest fails and names the field. A dictionary that arrives empty is refused rather than reported on — an export with blank names collapses into one object holding everything, which looks populated and is not.

What comes back

• An executive brief — the one-page read.
• A technical report — every finding with its owner, the action required and the test that closes it.
• An evidence appendix — what each finding rests on.
• A workbook — the findings as a spreadsheet, for tracking.
• The findings as JSON — against a published schema, for your own tooling.
• A lock file — every input hashed, the pack digests, and a rerun id.

How each finding is graded

NOT ASSESSED isn't a grade. It marks what a run didn't check, and it's never counted among the findings. Stated on every report, so a clean result's meaning is bounded.

Grade is severity. It is separate from how well the finding is evidenced, and both appear on every row — a BLOCKING finding from a dictionary observation alone is a different thing from a BLOCKING finding IBM's own upgrade script states, and a report that conflates them is not worth putting in front of a client.

What a finding carries

Five business days, from export to files

1. Day 0: Export received. Your dictionary, code and screens arrive. The clock starts here.
2. Day 1: Run against target release. Your export is compared with IBM's own release: upgrade scripts, compiled API, screens and dictionary.
3. Day 2: Graded findings. Every difference gets a severity and an evidence class.
4. Day 3: Owner review. Each finding gets its owner, its action and the test that closes it.
5. Day 4: Seven files delivered. assessment.md, assessment.json, brief.html, report.html, evidence.html, findings.xlsx, mxh.lock.json
6. Day 5: Rerun after fixes. Same inputs, same report. Your fixes show up as closed.

Founding Partner Pilot A$4,950 ex GST · Standard A$9,900 ex GST · Additional environment from A$3,500 ex GST.

Who each finding belongs to

Every finding names an owner — the customisation developer, the person in Application Designer, the DBA, or the partner — and states the test that closes it. A report that says what is wrong without saying who fixes it and how they know they have is a list, not a plan.

Run it again when you have fixed things

A rerun against the same inputs produces byte-identical output and the same rerun id. A rerun against a partly fixed system is compared against the original and every finding lands in one of 7 outcomes. The original record is preserved, so a finding can't quietly disappear.

• Verified resolved: Gone from the baseline, and the same source or JAR was scanned again this run — we looked at the same evidence and it is not there.
• Not reassessed: Gone from the baseline, but the surface that produced it was not part of this run: a file or JAR nobody supplied, or the customer's own data-dictionary export supplied to one of the two runs and not the other. Not a fix — supply the same surface again to find out whether it still applies.
• Invalidated by evidence correction: Gone from the baseline because mxh's own shipped evidence for the target release changed between the two runs, not because the customer's system did.
• No longer observed: Gone from the baseline with no code-coverage signal to verify against — typically a dictionary-only finding. Read as "not seen this time", not as a confirmed fix.
• Changed:
• Remaining:
• Newly observed:

Illustrative rerun, using real findings from the sample:

• psdi.iface.jms.ErrorQueueNotfCronTask no longer exists in 9.1 and your code references it → Verified resolved. The reference was replaced, and PermitGate.java:8 was scanned again.
• <presentation> sets 'resultsattribute', which 9.2 does not define for it → Not reassessed. The screen export was not sent the second time.
• ASSET.ASSETTYPE length 15 → 50 → Invalidated by evidence correction. MXH's own evidence for the target was corrected between runs.
• ASSET.PLUSSGEOJSON is removed on the path to 9.2 (no reference found in the code supplied) → No longer observed. A dictionary-only finding, not seen this time. Not a confirmed fix.
• Person.getAvailableHours(Date, PersonCalRemote, AvailCalc) → Changed. Still there, and something about it moved.
• ASSET.ASSETHEALTH type INTEGER → DECIMAL → Remaining. Identical in both runs.
• ASSET.KECORROSIONLOOP is not part of IBM's own 7.6.1.3 dictionary either → Newly observed. Present only in the second run.

An input that was removed gives "not reassessed", never "resolved". Same inputs, same report, byte for byte.

How far a fix is proven

1. Static analysis: the sample is here
2. Harness run: outstanding
3. Target compile/link: outstanding
4. Target runtime: outstanding
5. Business acceptance: outstanding

A ticket marked done is not verification. Accepted risk is not a fix.

What each report covers, exactly

Every report names its own boundary — what you sent, and how far the comparison reaches today — so a clean section means something exact rather than something hopeful. 1 screen field(s) run through a relationship path that was followed using the 9.2 relationship graph mxh ships, because your own MAXRELATIONSHIP export does not define the hop. Their attributes were checked against the 9.2 dictionary the same way every other field was, but which object each one lands on is IBM's out-of-the-box answer rather than yours — Application Designer lets a relationship be redefined, and a redefined hop lands somewhere else. Findings from those paths carry evidence class B2 and are graded for review; a clean result on them is weaker than a clean result on a path your own rows answered. `mxh import-dd` against your full MAXRELATIONSHIP extract settles it.

A report gives you counts you can check — sites found, sites closed — and your delivery team prices them. MXH counts sites, not days. It is not an IBM product and implies no IBM endorsement.