Context Lake

Port's Context Lake is your unified engineering knowledge layer—connecting data from across your entire toolchain into a single, semantically-rich source of truth. It's not a separate feature, but rather the powerful result of Port's core capabilities working together to provide organizational context that AI agents, developers, and workflows can understand and act upon.

What comprises the context lake

The context lake transforms scattered data across your engineering tools into unified organizational knowledge. It is built from four core components:

Software catalog

The software catalog is the heart of the context lake. It is built from two layers that work together:

• Data model - you define blueprints that represent the things your organization cares about: services, environments, teams, deployments, incidents, and more. Blueprints carry properties, relations, and metadata that encode what these concepts mean in your specific context.
• Data ingestion - your tools (GitHub, Kubernetes, PagerDuty, Jira, and 100+ others) continuously populate the catalog with real entities that match those blueprints, keeping your data fresh and accurate.

Together, these two layers make the catalog your organizational semantic layer - it teaches Port what "service," "deployment," or "incident" means specifically in your organization, providing the schema and populated data that gives AI agents, workflows, and dashboards something meaningful to act on.

Business context

Beyond technical metadata, the context lake enriches your software catalog with business context - the organizational, financial, and operational signals that help prioritize work, assess risk, and align engineering decisions with business objectives. This includes cost and revenue data, service criticality, team ownership, SLAs, compliance scope, and customer tier information.

When AI agents and workflows understand this context, they can prioritize vulnerabilities by business impact, route incidents to the right owner, estimate blast radius, and enforce policies automatically - all without manual triage.

For a full breakdown of what business context includes, example use cases, and how to model it in Port, see Business context.

Access controls - data governance

RBAC and permissions ensure that the right people and systems see the right data. Teams, roles, and policies control who can view, edit, or act on catalog data, maintaining security while enabling collaboration and providing governed access to your organizational knowledge.

Scorecards - your standards

Scorecards define and track your engineering standards, KPIs, and quality metrics. They encode organizational expectations—production readiness requirements, security compliance rules, operational best practices—as measurable criteria within the Context Lake, providing the organizational standards and quality signals that inform decisions.

Interface layer - how you access it

Context Lake data becomes actionable through multiple interfaces: Port AI Assistant and Port MCP server for AI-driven access, API for programmatic access, and Interface Designer with dashboards and visualizations that surface insights to your teams—providing multiple ways to query, visualize, and act on your organizational context.

External data via MCP Connectors

While the Context Lake provides structured organizational knowledge, MCP Connectors complement it by giving Port AI access to external tools like Notion, Linear, Jira, and other MCP servers. The Context Lake provides the modeled data (blueprints, entities, scorecards), while MCP Connectors provide real-time access to external data you wouldn't typically model like documentation, tickets, logs, and other just-in-time information. Together, they give AI agents both structured context and dynamic external data for more accurate responses.

The more your catalog data is modeled — entities related to one another, ownership clearly defined, scorecards encoding your standards — the more grounded and accurate AI responses become. MCP connectors then extend that foundation with live access to the parts you haven't modeled. Not sure which to use for a given tool? See Integrations vs. MCP connectors.

Why the context lake matters

For AI agents

Generic AI doesn't understand what "production-ready" means in YOUR organization, who owns which services, or how your deployment pipeline works. Context Lake provides this semantic understanding, enabling AI agents to:

• Answer ownership questions with definitive data (not guesses from code comments).
• Understand dependencies and relationships between services.
• Follow your organization's standards and guardrails when taking actions.
• Make decisions based on real-time operational context.

For developers

Instead of hunting across 10 different tools to understand a service's dependencies, ownership, deployment history, or incident timeline, developers get unified context in one place. The Context Lake connects the dots automatically.

Benefits:

• Quick access to service ownership and team information.
• Understand dependencies without switching between tools.
• See complete deployment and incident history in context.
• Get AI-powered insights based on your organization's actual data.

For platform teams

Define your organizational semantics once—service definitions, environment types, team structures, standards—and every tool, workflow, and AI agent can consume this shared knowledge. No more syncing configurations across systems.

Benefits:

• Single source of truth for organizational definitions.
• Consistent standards across all tools and automations.
• Reduced maintenance overhead from duplicate configurations.
• Enable self-service while maintaining governance.

Context lake in action - examples

AI agent understanding ownership

Developer asks: "Who owns the payments service?"

• Without Context Lake: AI guesses based on code comments or recent contributors.
• With Context Lake: AI queries the catalog → sees Team relation → returns the owning team with Slack channel and on-call schedule.

Autonomous service provisioning

AI agent needs to provision a dev environment:

• Without Context Lake: Agent doesn't know company's cloud standards, naming conventions, or cost limits.
• With Context Lake: Agent queries blueprints → understands allowed regions, naming patterns, tagging requirements → provisions correctly within organizational guardrails.

Incident response

Alert fires: "payments-api pod crashing"

• Without Context Lake: Engineer hunts through Slack, wiki, runbooks across multiple tools.
• With Context Lake: Port surfaces: recent deployments, related PRs, dependent services, ownership, SLOs, past incidents—all in unified context for faster resolution.

Getting started

Building your Context Lake is a natural part of setting up Port:

1. Define your data model - Create blueprints that represent your organization's entities.
2. Connect your tools - Ingest data from GitHub, Kubernetes, PagerDuty, and 100+ other integrations.
3. Set up relationships - Define how entities connect to each other.
4. Configure access controls - Ensure proper data governance.
5. Define standards - Create scorecards that encode your quality requirements.

As you build your catalog, you're simultaneously building your Context Lake—the unified knowledge layer that powers intelligent automation and AI-driven workflows.