An Exstream team usually has three relevant states: the latest work in the Design repository, the approved application, and the PUB package running or waiting for deployment.
Those states can differ for legitimate reasons. They can also differ because the wrong approval selection was packaged, a file was copied from the wrong build directory, or a late change never reached production.
A filename and package timestamp will not settle that.
Put both sides into one vocabulary
The repository and the package store related facts in different structures. A useful comparison first projects both into the same design-state document.
From the repository:
exstream-design-cli app state "Customer Letters" \
--profile production-copy --mode approved --depth detailed --json \
> repository-state.json
From the package:
exstream-package-cli state CustomerLetters.pub \
--depth detailed --out package-state.json
Both documents use the same object vocabulary and published JSON Schema. They carry the input identity, comparison depth, object inventory, known hierarchy, and explicit availability declarations.
The repository application can then be compared with the package:
exstream-package-cli diff repository-state.json CustomerLetters.pub \
--lineage same-lineage \
--population intersecting-populations \
--json-mode detailed \
--format html --out deployment-review.html
The lineage and population choices are explicit because they change the answer.
same-lineage says an object identifier refers to the same design object on both sides. That is appropriate when the package was built from the repository being inspected.
intersecting-populations says the repository application closure and package inventory overlap but are not identical populations. A package may carry supporting objects that the repository's application walk does not claim as members. Treating every package-only object as an addition would create noise rather than evidence.
Read the verdict and coverage together
A comparison should not collapse everything into "same" or "different". It needs to distinguish four outcomes:
- Differences were found in fields that could be compared.
- No differences were found, and every relevant field was comparable.
- No differences were found among comparable fields, but some fields could not be compared.
- Nothing was comparable, so the result says nothing about agreement.
Coverage is part of the verdict. If 9 percent of achievable field comparisons were possible, a clean result is weak evidence. If 99 percent were possible, the same clean result means much more.
Inspect reports not-comparable rather than converting an unavailable value to empty. This prevents the worst possible result: two unread fields being reported as agreement.
The changes reviewers actually care about
A repository-to-package review can expose changes such as:
- A customer-facing sentence gained or lost a literal or variable run.
- A formula or rule body changed by one condition.
- A variable changed type, compute time, default, or validation setting.
- A data-file field now populates another variable.
- An object version or property differs.
- A design object moved within the hierarchy where both sides preserve enough placement evidence.
The HTML review should arrange findings under the document and section that place them. A reviewer should not have to interpret a flat list of object identifiers to find the affected letter.
Decide which repository state you mean
"Compare production with the repository" is incomplete until you choose a repository mode.
Compare with approved when the release contract says only approved content may ship. Compare with latest when investigating whether an urgent edit reached the package. Compare with a named version when reconstructing a historical release.
Do not switch modes until one produces the answer you expected. Record the chosen mode in the report and explain why it is the correct side of the comparison.
A repeatable deployment check
A defensible deployment check looks like this:
- Take a read-only repository snapshot in the intended approval mode.
- Hash and inspect the exact PUB file entering deployment.
- Compare the two at the required depth.
- Review the verdict, coverage, changed objects, and unavailable fields.
- Approve the artifact digest, not merely its filename.
- Store the state and diff beside the release record.
Output tests show what selected inputs rendered. A design-state comparison shows which packaged rules, mappings, settings, and wording differ, including paths the test data did not render. Use both.
CCMForge Inspect uses this shared contract for repository, package, and historical-state comparisons.