W-23899752 content catalog jh - #552
Open
JennyHajee wants to merge 10 commits into
Open
Conversation
Document the Context Catalog capability for the Limited GA/MVP release: - Add Informatica Cloud Data Governance and Catalog (CDGC) scanner row (new Data scanner type) to the scanner prerequisites reference. - Describe the CDGC scanner's data-asset ingestion in the add-scanners page. - Add a new page for viewing data asset lineage: the Lineage tab, edge detection (observed/declared/inferred + confidence), node and edge types, the explorer, and use cases. Note lineage is Amazon (AWS Bedrock) only in MVP. - Wire the lineage page into the nav and add Context Catalog, Data asset, and Lineage glossary terms. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Rename exp-data-asset-lineage.adoc to exp-data-service-lineage.adoc. - Change "data asset" to "data service" throughout, and refer to the catalog as the Data Services catalog. - Update the page title, glossary term, nav entry, and cross-references. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Align the prerequisites row with the agent-scanner-configuration-service InformaticaCredential and InformaticaRegion definitions: - BASIC auth using IICS username and password (exchanged for a session token), plus a required Region, rather than an IDMC URL or client secret. - List the actual region options: NA, EMEA, UK, APJ, and Canada pods. - Drop the unenforced Catalog Administrator/User role requirement that appeared only in the prototype. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Explain in the lineage topic that creating an Informatica CDGC scanner is what brings in data services and enables lineage, with a new "How Data Services and Lineage Get Populated" section. - Reinforce in the add-scanners Informatica section that the scanner populates the Data Services catalog and enables agent lineage. - State consistently that lineage currently supports only agents discovered from Amazon (AWS Bedrock). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reference the Context Catalog Data Services catalog wherever the Portfolio catalog set is enumerated: - exp-portfolio-overview, exp-overview, exp-home-start, exp-services-add-to-portfolio, and the glossary Portfolio entry. - Gate each mention on the Context Catalog feature being enabled, and note that the catalog currently appears as "Data assets" in the UI (rename to "Data Services" pending). - Add the same UI note at the first Data Services mention in the Informatica scanner and lineage topics. Data Services is intentionally omitted from instances, conformance, and monitoring enumerations, which don't apply to data services. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Data Services catalog UI label was changed to Data Services, so the "currently labeled Data assets in the UI" notes and editorial comment are no longer accurate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Link the lineage page from the Monitor section so readers can trace the data services their agents consume. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
arampal-sf
reviewed
Aug 31, 2026
arampal-sf
left a comment
arampal-sf
left a comment
There was a problem hiding this comment.
Reviewed against our aligned Context Catalog positioning (the "dependency graph… position it as the map, not the pipes" one-pager). Net: docs are accurate and well-written, and the Agent → MCP → API → dataset chain lands cleanly. A few alignment asks before merge, detailed inline. Summary:
1. Re-anchor Use Cases to "one graph, four lenses." Our positioning names four lenses: Operational ("if I change this, what breaks?"), Governance ("what sensitive data can this reach?"), Cost & efficiency (bloated tool sets, idle assets, oversized models), and Deployment & hygiene (declared-vs-observed drift). The current Use Cases cover Operational + Governance well but omit Cost & efficiency and Deployment & hygiene / drift — and the drift material is already present in the declared-vs-observed edges.
2. Reconcile the detection taxonomy. The page uses Observed/Declared/Inferred in "How Lineage Is Detected" but Observed/Inferred (plus design-time-declared / runtime-observed) in "Edges and Provenance." Our aligned vocabulary is declared / observed / classified — let's decide where "Inferred" fits or drop it, and reserve "classified" for the Informatica/CDGC data-node labeling.
3. Position Context Catalog as the graph, not lineage as a sub-feature, and add the "keep it thin — resolve on demand" principle. Details inline.
Strong alignments to keep: Agent→MCP→API→dataset chain, "navigable graph," Observed=gateway telemetry, Declared=MCP Bridge config, confidence/provenance/timestamp on edges, and the honest Bedrock-only scoping.
| = Viewing Data Service Lineage | ||
| :keywords: lineage, data service, context catalog, agent fabric, informatica, cdgc, data lineage, agent to data, impact analysis, provenance, confidence score | ||
|
|
||
| Data service lineage connects your AI agents to the enterprise data services they consume, creating a navigable graph from agent to MCP server to API to dataset. Lineage is part of the Context Catalog capability in Agent Fabric, which is built on the Informatica Cloud Data Governance and Catalog (CDGC) integration. With lineage, Agent Fabric gains semantic awareness of what data an agent touches, how that data is classified, and what quality and policy constraints apply. |
There was a problem hiding this comment.
The Agent → MCP server → API → dataset chain here is exactly our aligned message — great. Two alignment tweaks:
- Framing: our one-pager positions Context Catalog as the dependency graph the whole product reads before it acts, with lineage/tracing/CDGC as how we build it. This sentence inverts that ("Lineage is part of the Context Catalog capability… built on CDGC"), which reads CDGC-first. Consider leading with Context Catalog as the navigable dependency graph, then noting lineage + CDGC as inputs.
- "Keep it thin" principle is missing: our positioning says lineage stores only the graph — auth, cost, classification, and credentials stay with their owning systems and resolve on demand. One sentence capturing that would align this with both the one-pager and the schema doc's resolve-on-demand pattern.
Reconcile exp-data-service-lineage.adoc with the lineage UI/label changes in mulesoft-omni-app PR 3038: - Empty-state message "asset version" -> "service version" - Broaden the Amazon-only limitation to trace-scanning only; the Lineage tab now covers agents, APIs, and MCP servers - Document the empty-state Tip and its next-step links - Node labels: "Unregistered asset" -> "Unregistered service" / "Not a registered service" - Lane/type labels: "Asset" -> "Service", "External" -> "Data source" - Document the "Scan for traces" control Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Apply arampal-sf's PR review feedback on exp-data-service-lineage.adoc: - Reframe the intro to position Context Catalog as the navigable dependency graph Agent Fabric reads before it acts, with lineage, tracing, and CDGC as how it's built (not lineage as a sub-feature) - Add the "keep it thin — resolve on demand" principle - Restructure Use Cases as "one graph, four lenses": Operational, Governance, Cost and efficiency, and Deployment and hygiene; fold explainability/root-cause/data-quality into Operational Detection-taxonomy reconciliation (Observed/Declared/Inferred vs declared/observed/classified) deferred to PM. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
aryanjain-sf
approved these changes
Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.