Searching an Exstream estate for customer-facing wording starts with scope and evidence coverage.
The phrase may sit in a paragraph, a page text box, a table cell, or a nested library component. Part of the sentence may be a variable reference. There may be approved and working versions, language variants, and old applications that still produce documents.
The result must say where it looked and which content it could not read.
Choose the state and estate scope
Start by deciding whether the question concerns approved production content, latest work, or both.
For a legal or brand review, approved content is normally the first pass. Latest work should be searched separately so a draft edit is not confused with deployed wording.
List the applications in scope from the repository rather than relying on a manually maintained application list. Record exclusions. An inactive-looking application may still support an annual run or a channel nobody remembers until it fails.
Search literal wording
Inspect performs a literal, case-insensitive substring search over decoded page and paragraph content and follows supported library-component references.
exstream-design-cli content search "policy number" \
--profile estate --app "Customer Letters" --mode approved \
--limit 100 --json > policy-number-search.json
Each match carries its hierarchy location and the matching text fragment. That lets a reviewer move from the phrase to the owning document, page, section, paragraph, or component instead of receiving a flat list of database rows.
Repeat the search per application, or drive it from the repository's application list. Keep the result files. Search output is evidence only when another person can tell which repository, mode, application, term, and tool version produced it.
Search variable references separately
Literal search cannot find a value that enters the document through a variable at runtime.
If the wording review concerns a known variable, search its placements:
exstream-design-cli content search \
--variable PolicyNumber --resolve-names \
--profile estate --app "Customer Letters" --mode approved \
--json > policy-number-variable-uses.json
Variable runs remain references rather than being replaced by the Designer sample value. That distinction prevents test data such as 123456 from being reported as customer-facing literal wording.
For a phrase assembled from several variables and literals, inspect the surrounding runs and the formulas or data mappings behind those variables. Searching the rendered sample string in the repository is not enough.
Use extraction for a whole-estate review
When the job is translation, terminology review, or content rationalization, repeated keyword searches are the wrong primary artifact. Extract the decoded content in hierarchy order:
exstream-design-cli content extract "Customer Letters" \
--profile estate --mode approved --output csv \
> customer-letters-wording.csv
The structured JSON form preserves ordered runs, variable identifiers, language identity, hierarchy location, and decode status. CSV is convenient for reviewers, but keep the JSON when another system needs to distinguish literal text from references.
Always read the accounting
Search results include accounting for decoded, partial, and unknown content.
decoded means the selected text body was searchable. partial means some cells or nested members were searchable and others were not. unknown means no text slice from that row could be searched safely.
Unknown content is excluded from matching. It is never guessed from nearby bytes.
This changes how you report a clean result:
- "No matches in fully decoded content" is a useful statement.
- "No matches, with 14 partial and 3 unknown bodies" requires follow-up.
- "The phrase does not exist in the estate" is only defensible when the estate scope and relevant content coverage support it.
Also check whether the result hit the requested limit. A truncated result is not a complete occurrence count.
Search the variants people actually use
Real wording reviews need more than one exact phrase. Search punctuation variants, old and new terminology, abbreviations, non-breaking-space behavior, and language-specific forms.
Do not create a huge regular expression and lose the audit trail. A small search manifest with one term per line is easier to review, rerun, and sign off.
For each term, capture:
- The reason it is included.
- Literal matches and variable-reference matches.
- Applications and modes searched.
- Result counts and truncation.
- Partial and unknown content counts.
- Reviewer disposition for every match.
Follow each match into impact analysis
Finding a sentence tells you where the literal is stored. It does not tell you every document that can reach a shared component or whether a runtime rule emits it for a given customer.
Follow shared-object placements, application dependencies, rules, and data mappings before estimating the change radius. Then compare the approved state before and after the edit so the review records exactly what changed.
CCMForge Inspect can produce the wording extract, variable-reference search, repository hierarchy, and before-and-after design diff used in this workflow.