A PUB file is often the last trustworthy artifact in an Exstream deployment. The source repository may be on another network, the person who packaged the application may be unavailable, and the deployment ticket may say little more than a filename. Yet the package is the thing the engine will run. You can inspect what it contains without Designer or a Design Database. CCMForge Inspect includes a Package CLI that reads the package directly and never modifies it.
Start with identity, not detail
Before reading formulas or wording, establish which artifact you have. A package overview should record the application name and path, application version, package creation date, Design Manager version, approval selection, and a SHA-256 digest of the exact file.
The digest matters. A report without a digest can drift away from the file it describes as soon as someone renames or replaces the package.
Run the ordinary report first:
exstream-package-cli CustomerLetters.pub --format json --out package.json
The standard report inventories the objects without exposing every code or text body. It is usually enough for an initial check and safer to share than a detailed report.
What the package can tell you
A current classic package can expose much more than an application name. Depending on the package generation, the report can include:
- Counts and identities for documents, pages, paragraphs, variables, rules, functions, data files, fonts, output objects, and other packaged object types.
- Variable types, calculation methods, compute timing, defaults, validation settings, and privacy settings.
- Formula, function, and rule source where the package stores it and the decoder supports that generation.
- Data-file mappings, including the variable each field populates.
- Customer-facing wording from supported text-bearing objects, with variable references kept separate from literal text.
- Object versions, last-edit values, and package ownership fields where the package carries them.
For code and wording, request detailed mode:
exstream-package-cli CustomerLetters.pub \
--format json --json-mode detailed --out package-detailed.json
Detailed output is customer data. It can contain proprietary business rules, local paths, mappings, and literal correspondence text. Store and share it accordingly.
For a human review, an HTML state page is usually better than raw JSON:
exstream-package-cli state CustomerLetters.pub \
--depth detailed --format html --out package-overview.html
The result is one self-contained file with a searchable object tree, inventory counts, settings, mappings, code, and wording. It does not fetch scripts or data from the internet when opened.
Read the coverage before trusting an empty result
Not every PUB generation stores the same structures in the same way. An old package may yield a complete inventory but only partial variable settings or formatted text. A package from an untested future generation may parse without having the same validation evidence as a known release.
This is where weak inspection tools get dangerous. They show an empty field, and the reader assumes the object had no value.
Inspect reports the package generation and the status of each decoder. In the shared design-state document, unavailable paths are declared as not-in-source, not-decoded, or not-stated. An absent value is only a fact about the design when the corresponding path was available.
So "no matching wording found" and "this wording was not decoded" are different results. Keep them different.
What a package cannot prove alone
A PUB file describes the compiled artifact. It does not replace the repository.
In particular, a package alone cannot reliably answer:
- Which draft objects exist in the repository but were not packaged.
- Whether the package matches the currently approved application.
- The full authoring hierarchy where the package format does not preserve containment.
- Why an object changed or which Design Manager event introduced the change.
- Whether an object that appears unreferenced is safe to delete from the repository.
Those questions need repository evidence, or a comparison between the repository and the package.
First review checklist
When a package arrives with a deployment or support case, I would check it in this order:
- Record the file digest and package overview.
- Check the application identity, creation date, Design Manager version, and approval selection.
- Scan counts by object type for obvious surprises.
- Inspect the data files, variable mappings, formulas, rules, and wording relevant to the change.
- Read decoder support and availability before treating an empty field as evidence.
- Save the report beside the package so the two remain tied together.
If the package should match a known repository state, compare the two directly after this first review.
Send one PUB package and get a free HTML overview. The file is enough for the first pass.