The evidence behind the decision.

One assessed result, one set of counts, and a trace from every decision to its evidence.

Classification contract

Verification state

These reports record assessment evidence and proposed closure tests. Runtime execution and business acceptance are pending unless a separate result explicitly records them. A corrected assessment finding is an evidence correction, not completed customer remediation.

Assessment coverage and evidence requests

• 1 unresolved presentation-binding occurrences are retained individually under coverage.presentationUnresolved in assessment.json. They are not successful checks or additional confirmed defects.
• 14 attribute reference(s) in the supplied code could not be tied to an object, so they were NOT checked: the file names no object (no launch point for the script, no `mboname`/`objectName`, no `mxh:object=` comment). Supply the SCRIPTLAUNCHPOINT export so each script's object is known, or add a `# mxh:object=<OBJECT>` line to the file. First sites: examples/customer-upgrade/src/java/com/kestrel/maximo/PermitGate.java:23, examples/customer-upgrade/src/java/com/kestrel/maximo/PermitGate.java:24, examples/customer-upgrade/src/java/com/kestrel/maximo/PermitGate.java:33, examples/customer-upgrade/src/java/com/kestrel/maximo/PermitGate.java:41, examples/customer-upgrade/src/scripts/KESHUTDOWN.py:8, examples/customer-upgrade/src/scripts/KESHUTDOWN.py:9, examples/customer-upgrade/src/scripts/KESHUTDOWN.py:10, examples/customer-upgrade/src/scripts/KESHUTDOWN.py:12.
• 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.
• 1 screen field(s) run through a relationship this run could not follow, so they were not checked: WORKORDER.KEWELLHEAD. Neither your own MAXRELATIONSHIP export nor the 9.2 relationship graph mxh ships defines a relationship of that name on that object. An export scoped to some objects does not carry every relationship, so this is missing evidence rather than a broken screen — it is not reported as a finding.
• No automation-script launch points were supplied, so what fires each script was not checked — only what the script does. A script whose code has not changed still breaks when the column its launch point binds to is gone at the target, and no code scan can see that. Export `SCRIPTLAUNCHPOINT` and `LAUNCHPOINTVARS` and point the manifest's `launch-points` surface at them.
• No configuration export was supplied, so your own escalations, cron task instances, actions, workflow conditions, communication templates, domain values and property values were NOT checked. An escalation whose condition names a column the target dropped does not fail at import; it fails on its first run, in a log. Export `ESCALATION`, `ESCREFPOINT`, `CRONTASKDEF`, `CRONTASKINSTANCE`, `ACTION`, `WFPROCESS`, `WFCONDITION`, `COMMTEMPLATE`, `MAXDOMAIN`, `SYNONYMDOMAIN`, `ALNDOMAIN` and `MAXPROP` as JSON and point the manifest's `configuration` surface at them.
• No security export was supplied, so **who** each finding above affects was not assessed — only what it breaks. Security-group grants and restrictions are a customer's own rather than IBM's, so nothing shipped can answer it: a restriction pointing at a column the target dropped stops applying silently, and rows it was hiding become visible with nothing in any log to say so. Export `MAXGROUP`, `APPLICATIONAUTH`, `SECURITYRESTRICT` and group membership **as counts** (`SELECT groupname, COUNT(*) ... GROUP BY groupname` over active users — never user ids) and point the manifest's `security` surface at them.
• Shipped configuration is compared — action, application, commtemplate, crontask, doctype, endpoint, escalation, intobject, kpi, property, report, restriction, securitygroup, sigoption, workflow — and a difference becomes a finding where the supplied code names it. Configuration reached only from the database (an escalation whose action row points at a class, a report the code never names) is not seen by a code scan, and neither are security-group grants or menu placement, which are a customer's own rather than IBM's. Those come in from the customer's own configuration export, the same way `--export` brings their dictionary in.
• `object-structures` was declared not supplied by Kestrel Energy — the integration framework was not exported for this engagement, so no object-structure schemas were available to check. `mxh assess` now reads them when supplied: point the manifest's object-structures surface at a directory of the customer's own exported OSLC `/oslc/jsonschemas/<os>` responses (or an OpenAPI document) and every field one publishes outside the code-scanned objects is compared against the target dictionary the same way a plain attribute is.
• `launch-points` was declared not supplied by Kestrel Energy — the automation scripts were exported as source only, so SCRIPTLAUNCHPOINT and LAUNCHPOINTVARS were not taken and what fires each script was not checked — only what it does. `mxh assess` now reads them when supplied: point the manifest's launch-points surface at the customer's own export of those two tables and every object and column a trigger binds to, plus every variable bound to a bare attribute, is compared against the target dictionary the same way a plain attribute is.
• `java-inventory` was declared not supplied by Kestrel Energy — no JAR inventory was taken for this engagement, so only the Java under src/java is scanned for psdi references. `mxh assess` now reads compiled JARs too when supplied: point the manifest's java-jars surface at the customisation's lib directory (or a WAR's WEB-INF/lib) and every class file's constant pool is checked for removed psdi signatures the same way source is — no execution, no classloading.
• Dictionary differences that need no work, so not raised: 2 where IBM's own 7.6.1.3 definition already matches 9.2 (the difference is your customisation, and an in-place upgrade carries it), 54 where 9.2 only relaxes the column (longer, or a type that accepts more), so every existing value and consumer still fits, and 0 fields of yours that 9.2 defines identically.
• 5 of your own columns bound on your screens are already listed as local extensions; the upgrade carries the column and the binding, so the screens raise nothing further for them.
• 1 control property set on your screens is defined by neither the 7.6.1.1 nor the 9.2 release, so the screens ignore them today and will on 9.2. Not raised as findings.
• 8 IBM objects and columns removed on the path to 9.2 are used by nothing you supplied, so the upgrade drops them with no work on your side; if you keep rows in any of them, export those rows before cutover: FAILUREREPORT.EXCEPTIONDATE, FAILUREREPORT.EXCEPTIONREASON, FAILUREREPORT.EXCEPTIONREFERENCE, FAILUREREPORT.IMMEDIATEACTION, FAILUREREPORT.QUALITYIMPACT, FAILUREREPORT.READYTOUSEAFTERCORRECTION, FAILUREREPORT.USEDAFTEROVERDUE, LOCATIONS.PLUSSGEOJSON.

Rule provenance

Information register

Evidence appendix · Machine-readable assessment · Input and output hashes

MXH is not produced, endorsed, certified or supported by IBM. Counts of findings, not of days.