OIC mod hash explained: how Oracle locks IAR exports

The mod field at icspackage/project/<PROJECT>/ics_project_attributes.propertiesis OIC's integrity check. It is the single piece of metadata that decides whether your re-import succeeds or fails with ICS-20099.

Anatomy of the field

mod=csiyL2JIDTnU8K10o63Xlw==

The value is base64 of a 16-byte (128-bit) digest. That length matches MD5 — but treating it as MD5 of any obvious normalised input does not match in our tests.

What we tried (so you don't have to)

• MD5 of project.xml alone. Does not match the mod on any of the eight production IARs we tested.
• MD5 of canonicalised project.xml (whitespace + attribute ordering normalised). Closer in structure but still does not match.
• MD5 of the concatenated zip entry list (sorted) plus the bytes of each. The most plausible candidate; we have not been able to reproduce it deterministically because the OIC server does its own per-file canonicalisation (line-ending normalisation, attribute reordering in XML).
• MD5 of just the "significant" resources (XSLs + WSDLs + project.xml). Also does not match.

What the hash tells us about Oracle's intent

The presence of an integrity hash, server-side validation, and Oracle's explicit policy in MOS 2896228.1 all point in the same direction:

OIC is designed as a closed authoring loop, not as a build-system input. The Designer is the integration's compiler; the IAR is the build artifact. Oracle treats the situation the way Apple treats iOS app signatures: the integrity check exists to guarantee the artifact came from a trusted producer.

If your team treats the IAR as an editable source file, you're fighting the platform's design. That is not a critique of either side — it's a statement that file-based integration platforms and UI-based integration platforms are fundamentally different categories, and OIC is the latter.

Implications for automation

If you need a file-based platform

Then OIC isn't the right fit. ERPHive's entire architecture inverts the OIC model: the source of truth is a directory of plain text files, the runtime reads those files, and the Designer (the visual flow render) is a derived view from the files — not a producer of opaque archives.

You can see the difference by running our migrator: drop any OIC IAR on erphive.com/migrate and the equivalent ERPHive flow.yaml is generated in under a second. The result is text you can diff, review, and merge — no mod hash, no integrity wall.