MXH · Documentation

What MXH checks today, and what is next.

Choose the upgrade-assessment or developer-testing workflow, see which inputs each uses, and understand the evidence it produces. Current capabilities and planned work are labelled throughout.

The assessment runs locally over your export. It compares definitions and code without executing your customisations. Developers can also use the separate modelled local test harness.

BUILT NOW — shipped and working today.

Read your Maximo export. Compare it with the target release.

MXH reads the setup you supply locally and compares it with versioned release evidence. Findings show the differences in the supported checks, with their source and confidence.

It covers data definitions, customisation code, classic Application Designer screens, role-based MAF definitions and supported configuration exports. The report identifies which inputs were assessed and the release evidence used for each finding.

1. Supply: export the data setup, customisation code and screens you want assessed.
2. Compare: run those inputs against the exact Maximo release you are targeting.
3. Act: work from findings that are graded, evidenced, owned and closable.

Run it yourself, in six steps.

Core tool: free. Versioned metadata packs: separate evaluation and subscription terms. Run the assessment on your own machine, over your own export, and read the report yourself.

1. Step 1: Get MXH. Request the package and first-run instructions by email at /mxh/start. The core tool is free; metadata packs have separate evaluation and subscription terms.
2. Step 2: Export your Maximo. Your data dictionary, customisation code and screens, plus a manifest. Structure only, no business records.
3. Step 3: Run it. One command over one folder. MXH compares your export with IBM's own release for your target.
4. Step 4: Read the findings. Every difference has a severity, an evidence class, an owner and the test that closes it.
5. Step 5: Use the 13 files. assessment.md, assessment.json, brief.html, report.html, evidence.html, findings.xlsx, mxh.lock.json, architecture.html, assurance.html, engineering.html, explorer.html, preflight-db2.sql, programme.html
6. Step 6: Rerun after fixes. Compare the new run with the original. Closure follows the evidence checked; omitted inputs are never counted as fixes.

Core tool: free. Versioned metadata packs have separate evaluation and subscription terms.

Request MXH for an emailed package and setup instructions. Stuck on a step? Email aniruddh@assetize.com.au.

Three ways to run it. Start with whichever you can export this week.

A full audit is the most thorough, and it is not the only way in. Each mode below produces a real report; the narrower ones simply say so about what they did not receive.

Start with the inputs you have and add the rest to a rerun. Compare the second report with the first to distinguish changed findings, new observations and items no longer observed.

Three parts of your system go in.

• Data setup — the structure and configuration supplied for assessment.
• Customisation code — the local code whose assumptions need to survive the target release.
• Screens — classic presentation XML and role-based MAF app.xml checked against release evidence.

If you do not supply something, or the comparison does not cover it yet, the report says so. A quiet section never stands in for proof that your system is clean.

What to export, and where it comes from.

Choose the inputs for the questions you want answered. Keep the files locally, and record their release, date and scope in the assessment manifest.

• The data dictionary — five tables: MAXOBJECT, MAXATTRIBUTE, MAXRELATIONSHIP, SYNONYMDOMAIN and ALNDOMAIN. Read-only SELECTs, one CSV per table with a header row. A REST fetcher ships with the product if you would rather pull it over the API than run a database export, and a lower environment that matches production customisations is the better place to take it from.
• Structure, not records. The export is your schema — object and attribute definitions. No work orders, no assets, no business rows. Worth saying twice, because it is the first thing a security review asks.
• Your customisation code — custom Java, automation scripts, or both. Compiled JARs support reference and signature checks. If what is deployed and what is in source control disagree, say so in the manifest rather than picking one.
• Your screens — Application Designer presentation XML and role-based MAF app.xml definitions. Include object-structure schemas for custom datasources.
• Integration and script bindings — exported OSLC object-structure schemas or OpenAPI definitions, plus launch-point and variable-binding JSON. These expose dependencies beyond the code itself.
• Your configuration — supported JSON exports for escalations, cron tasks, actions, workflows, communication templates, domains, properties, integrations and KPIs; BIRT .rptdesign files; installed-product and source-level records; and the Integrity Checker log. MXH checks their referenced fields, classes and definitions.
• Security definitions — MAXGROUP, APPLICATIONAUTH, SECURITYRESTRICT and group membership counts as JSON. These relate findings to affected groups and identify restrictions that reference changed fields. No user identities are needed.
• A manifest — the release you are on, the target, the add-ons installed, the export date, and anything you are holding back with the reason. A manifest that contradicts itself fails the run rather than quietly producing a report against the wrong baseline.

Packaged configuration describes IBM-shipped definitions. Your configuration export adds the changes and dependencies specific to your estate. Review configuration files for credentials and secrets before including them.

The manifest records supplied and omitted inputs. A preflight inventory shows what the package contains before the assessment, so you can add missing inputs deliberately.

Every finding carries four separate decisions.

• Severity: will this stop the system, require review, depend on the environment, or sit outside the assessment?
• Confidence: 6 evidence classes keep a certain observation separate from a probable interpretation.
• Owner: the row names who fixes it, so the project does not have to argue about it.
• Closure: a specific, checkable condition proves the item is fixed; a status field by itself does not.

Severity and confidence never collapse into one score. A serious but uncertain finding must not read like a certain failure, and a well-evidenced minor observation must not be inflated into a blocker. Read the evidence classes or inspect the finding shape in the sample assessment.

Test customisations locally with a modelled harness.

Developers use MXH with JUnit to run selected custom code against version-aware, in-memory MBO models and generated fixtures. This is a separate workflow from the static upgrade assessment.

1. Prepare a project. Request the package through Get MXH, use Java 17 or newer, and run mxh init in your customisation repository to create the project configuration.
2. Choose the model and data. Select the generally available release profiles you need, such as mas-9.0, mas-9.1 or mas-9.2. Generate fixtures and include your exported dictionary when testing local extensions.
3. Write focused tests. Use @MaximoTest for a profile and @MaximoMatrix for selected profiles. Exercise Java customisations, Jython scripts, headless classic-screen interactions or local OSLC contracts against the model.
4. Keep the evidence. Retain the test results, generated fixtures, configuration and lock file in your development or CI workflow. Review the modelled rules and their assumptions alongside failures.

• Static comparison: reads exported definitions and code references. Produces version-specific findings for developers, architects and upgrade leads.
• Modelled local testing: executes selected custom code against the harness model. Gives developers and QA teams repeatable tests for the behaviours they cover.
• Customer-target evidence: records what ran on the configured customer target, with its inputs and results. Keep this evidence separately for integration, business-process and acceptance decisions.

A local test result describes the selected model and fixtures. Target execution has its own evidence record; the assessment and local harness results are kept as distinct inputs to that decision.

Compiled JARs support static checks too.

MXH reads class references and signatures from compiled customisations, so API comparison can include code you only have as a build artefact. The assessment reads your classes without running or decompiling them, and nothing is installed on your Maximo.

The answer is the same every time: two runs over the same JAR agree down to the byte.

Where the release knowledge comes from.

Every fact MXH compares against is drawn from material IBM publishes and from the shipped product itself — release documentation, the upgrade scripts that come with a release, and the release's own declared definitions. Each finding cites the specific thing it came from, so you can go and read the source yourself.

What the product carries is facts about those releases: names, types, lengths, signatures, and what a given upgrade script changes. IBM's files, code and documentation text stay with IBM. MXH is not an IBM product and implies no IBM endorsement.

The same inputs produce the same assessment.

Every supplied input is fingerprinted. Repeating an assessment over the same inputs produces byte-identical output rather than a merely similar report. After remediation, compare the new run with the original. The rerun distinguishes verified closure, evidence corrections, omitted inputs and changed observations. The earlier record stays visible; an input omitted from the rerun is never counted as a fix.

• 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:

Coverage is tied to explicit release data.

This site starts at Maximo 7.6.1.3 and publishes 3 release lines, 3 release moves and 18 industry add-ons from the integration package. Availability is shown for each release. The baseline can provide graded release-to-release numbers before customer code is supplied, and industry add-ons can be included where their package data is represented.

84,034 attributes counted across those 3 releases together. This is a cross-release total, not a count of unique attributes.

Those are the dictionaries. The level you move from is a separate question. This site's classic Maximo source choices start at Maximo Asset Management 7.6.1.3. For Maximo IT, check the IBM Control Desk 7.6.1.5 and Maximo Asset Management 7.6.1.3 requirements. Confirm the installed source and target against IBM's upgrade checklist. Where a source dictionary is unavailable, findings come from IBM's upgrade scripts and are labelled script-stated. The numbers are on the hub.

Use the interactive release and add-on explorers for the package-derived detail behind these totals.

Explore the 13 packaged sample files.

These sample files show how the outputs support executive decisions, technical remediation, evidence review, delivery tracking, automation and repeatability.

• Executive brief — the decision-ready summary.
• Technical report — every finding, owner, required action and closure condition.
• Evidence appendix — the evidence behind each finding.
• Tracking spreadsheet — findings in a format a delivery team can own.
• Machine-readable findings — the assessment as structured data.
• Plain-text rendering — a stable form for diffing between runs.
• Fingerprinted run record — the fingerprinted record of exactly what was checked.
• architecture.html — a package-owned file produced by the assessment.
• assurance.html — a package-owned file produced by the assessment.
• engineering.html — a package-owned file produced by the assessment.
• explorer.html — a package-owned file produced by the assessment.
• preflight-db2.sql — a package-owned file produced by the assessment.
• programme.html — a package-owned file produced by the assessment.

A full assessment also produces readiness.html, readiness.md and readiness.json: upgrade work grouped by what to fix, reconfigure, retest or clean up, with ownership, evidence and completion conditions.

Every report also states what it did not inspect. The absence of findings only has meaning when the assessment boundary is visible.

The same assessment answers a different question for each seat.

• Executive sponsor — should we commit?
• Programme manager — what is in scope?
• Maximo lead — what changes for my users?
• Technical lead — how is this verified?
• Business Partner — how do I scope this before I have access?

The configuration IBM ships is compared, not just the dictionary.

Reports, KPIs, cron tasks, escalations, workflows, security options, groups and restrictions, applications, properties, actions, templates, integrations, endpoints and document types. Shipped definitions are compared, and referenced differences become findings.

Your own configuration and security exports extend this comparison to customer-specific expressions, class references, integrations, grants and restrictions. Each finding is tied to the supplied definition and the release evidence behind the check.

What fires an automation script is checked, not just what it does.

Launch points are a declared input. The object and column a launch point fires on, and every variable bound to an attribute, are checked against the target exactly as a plain attribute is.

A script whose code has not changed a character is caught when the column its trigger binds to is gone or has changed shape. No scan of the source can see that.

A baseline composed from several industry add-ons at once.

An assessment folds in as many add-ons as you run, in a declared order, so the starting point is the system you actually run rather than base Maximo plus a guess.

Where two add-ons put the same column on the same object, the report says which definition applies and why. Where install order decided it and no IBM artefact records which one won, it says that instead of picking, and names the query you run to read it off the system.

A binding followed through a relationship path.

Screen fields and script variables alike are followed to a real object at any depth, and every finding is graded by which graph answered each hop.

A path your own relationship rows answer is graded like any other binding. A path needing a hop from the shipped graph says so and never blocks. A hop nothing answers is reported unresolved with the hop named, rather than resolved against the wrong object.

Prove it closed, after the upgrade.

Run the assessment again once you have moved and every finding comes back closed, not closed, or could not be checked, with the lines that say what was looked at.

Closed means the finding was looked for again in the evidence it was read off and is not there. A surface nobody supplied is never a closure, so a finding that vanished because nobody sent that evidence the second time is never reported as fixed.

Role-based MAF definitions are checked today.

Supply app.xml definitions to check datasource object structures, selected attributes, bindings, elements and properties against the available release evidence.

These are static checks on the application definitions. Findings identify the registry used and carry an exploratory confidence class when the comparison uses a nearby release registry. Classic presentation checks and modelled headless classic-screen tests remain separate workflows.

What is next

The following work is planned. No date is promised.

Model more of Maximo’s behaviour.

50 cited behaviour rules across 24 objects today, each with its assumptions stated separately. Further rule coverage is planned against the measured behaviour gaps.

Track new IBM releases automatically.

Automatic release-reference refresh is planned so comparisons stay version-specific as new supported levels appear.

MXH integration package 703dc515119b23f7