diff --git a/vault/03-context/systems/fid4.md b/vault/03-context/systems/fid4.md
index 380e360..fe416d0 100644
--- a/vault/03-context/systems/fid4.md
+++ b/vault/03-context/systems/fid4.md
@@ -33,6 +33,8 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo
 - When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope.
 - Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint.
 - Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published.
+- Fidelity uses internal build-distribution tooling such as `iosinstaller` to inspect shipped consumer builds.
+- `iosinstaller` can provide App Store and internal build downloads and expose the build's `Podfile.lock`, which makes it a useful validation source when the repo itself does not track that lockfile.
 - The common update path is:
   - modify the Podfile to the new XFlowViewMaker version
   - run `tuist generate -n`
@@ -40,6 +42,7 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo
   - open and merge a PR
   - wait for the consumer team to carry the change forward in their normal App Store release flow
 - `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles.
+- A useful app-store validation path is the Flagship app pipeline artifacts: `appstore/DistributionSummary.plist` records the framework versions installed in that build and can be used to confirm which XFlowViewMaker and XFlow versions were actually shipped.
 
 ---
 
diff --git a/vault/03-context/workstreams/consumer-integration.md b/vault/03-context/workstreams/consumer-integration.md
index 4fe605c..15e09b0 100644
--- a/vault/03-context/workstreams/consumer-integration.md
+++ b/vault/03-context/workstreams/consumer-integration.md
@@ -89,6 +89,7 @@ Capture the durable release and validation path between XFlow changes and real c
 - The fastest reliable signals are:
   - fixed version references in the Podfile when present
   - archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
+- Useful Fidelity-specific sources include `iosinstaller`, which exposes App Store/internal builds plus their `Podfile.lock`, and the Flagship app pipeline artifact `appstore/DistributionSummary.plist`, which records the framework versions included in a shipped build.
 - Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
 - When a consumer build must be reproduced exactly from an older dependency snapshot, `Podfile.lock` alone may still be insufficient if the private podspec repo changed afterward; the stronger reproduction path is to align the podspec repo revision too.
 - A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
diff --git a/vault/06-daily/2026-04-17.md b/vault/06-daily/2026-04-17.md
index ed13a29..c57f5dd 100644
--- a/vault/06-daily/2026-04-17.md
+++ b/vault/06-daily/2026-04-17.md
@@ -88,3 +88,10 @@ tags:
 - Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior.
 - David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced.
 - If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone.
+
+## Learning Correction - Build Inspection Sources
+
+- David clarified that `iosinstaller` is one of Fidelity's internal apps for inspecting distributed consumer builds.
+- `iosinstaller` can download App Store and internal builds and also expose the corresponding `Podfile.lock`.
+- David also clarified a useful app-store debugging path in the Flagship app pipeline: the artifact `appstore/DistributionSummary.plist` records the framework versions installed for that build.
+- That artifact can be used to confirm which XFlowViewMaker and XFlow versions were actually installed in a specific App Store build.