Glossary
Port uses several proprietary terms that either carry specific meaning within Port or collide with common industry concepts. This page defines each term precisely to eliminate ambiguity.
Terms are listed alphabetically.
Run
A single execution of a workflow or self-service action, including its inputs, status, logs, and audit trail. Runs are stored in Port and can be inspected after the fact to understand what was triggered, by whom, and what the outcome was.
AI agent
A Port-native AI agent that can query the software catalog, trigger self-service actions, and answer questions using Port as context. Distinct from generic AI agents - a Port AI agent has direct access to your catalog data model and organizational context.
Automation
An event-triggered workflow in Port that executes automatically when a catalog event occurs - for example, an entity was created, a property changed, or a timer expired. Distinct from a self-service action, which is triggered manually by a user.
Blueprint
Port's schema definition for a catalog type. A blueprint defines the structure (properties, relations) that all instances of that type share - for example, "Microservice", "Environment", or "Team". Not to be confused with an architecture blueprint or system design document. In Port, a blueprint is closer to a class definition in object-oriented programming.
Catalog auto-discovery
Port's ability to automatically detect and ingest resources from connected tools without requiring manual mapping configuration. When enabled, Port scans connected integrations and proposes or creates entities based on what it finds.
Context Lake
Port's aggregation layer that collects catalog data, events, and metadata to provide AI agents and tools with rich organizational context. The Context Lake is what makes Port-connected AI agents aware of your specific infrastructure, services, and relationships.
Data source
The configuration object in Port that represents a connected integration and its sync settings. Each installed integration creates a data source entry in your portal, which controls how data is fetched and mapped into the catalog.
Entity
A catalog record - a concrete instance of a blueprint. If "Microservice" is a blueprint, then "payment-service" is an entity of that blueprint. Entities hold the actual data (property values, relation links) for each resource tracked in Port. Not to be confused with a generic ORM entity or domain entity in domain-driven design.
Integration
In Port, an integration is an Ocean-based connector that syncs data from a third-party tool (GitHub, Jira, AWS, Datadog, and others) into the software catalog. The term is specific to Port's integration layer and is not a generic synonym for any API connection.
Level
A tier within a scorecard (e.g., Basic, Bronze, Silver, Gold). An entity reaches a level when all rules defined for that level pass. Levels are ordered - an entity must satisfy lower levels before achieving higher ones.
Mapping
The JQ-based configuration within a data source that translates external tool data into Port entities. Mapping defines which data maps to which blueprint and what value each property receives.
MCP server
Port's implementation of the Model Context Protocol (MCP), which exposes catalog data and self-service actions to external AI tools such as Claude, Cursor, and GitHub Copilot. Connecting an AI tool to Port's MCP server gives it live access to your catalog and the ability to trigger actions on your behalf.
Ocean
Port's open-source integration framework used to build and run integrations that sync data from external tools into the software catalog. Ocean is Port-specific - it is not a general industry term. When Port documentation refers to "Ocean integrations", it means integrations built on this framework.
Ownership
The mechanism in Port for assigning a team as the responsible owner of an entity. Ownership is used to drive accountability, filter catalog views, and scope RBAC permissions - for example, restricting who can trigger actions on a given service.
Page
A customizable view within Port's portal. Pages can display catalog tables, dashboards, entity detail views, or embedded content. In Port, "page" refers specifically to a portal view, not a generic web page.
Portal
Port's developer portal product - the web application at app.getport.io where developers interact with the catalog, run self-service actions, and view scorecards. "Your portal" refers to your organization's Port instance.
Property
A field defined on a blueprint that holds data for each entity (e.g., language, repo_url, on_call_contact). Port supports many property types including strings, numbers, booleans, URLs, and various computed types.
RBAC
Role-based access control as implemented in Port. Port's RBAC model controls which users can view, create, edit, or delete entities and blueprints, and who can trigger self-service actions. Default roles include Admin and Member; teams can also be used to scope permissions.
Relation
A typed link between two blueprints that models dependencies or ownership in the catalog (e.g., a Microservice belongs to a Team, a Deployment references an Environment). Relations in Port are directional and defined at the blueprint level - not to be confused with a relational database foreign key.
Rule
A single condition within a scorecard level (e.g., "has_owner = true", "response_time < 200"). Rules evaluate entity property values and return pass or fail for each entity.
Scorecard
Port's mechanism for tracking compliance, quality, and maturity standards across catalog entities. A scorecard defines a set of levels and rules and evaluates each entity against them. Not a generic KPI dashboard - scorecards in Port are integrated directly with the catalog data model and update in real time as entity data changes.
Self-service action
A user-triggered workflow in Port that lets developers perform predefined operations (provision resources, open tickets, deploy services) directly from the portal. Distinct from automations, which are triggered automatically by catalog events rather than by a user. Often shortened to "action" in Port documentation.
Skill
A reusable AI capability registered in Port that AI agents can invoke to perform specific tasks (e.g., deploy a service, open a pull request, query the catalog). Skills are defined once and can be called by any agent that has access to them.
Software catalog
The central registry in Port that contains all entities, organized by blueprints and linked by relations. The software catalog is the core of Port, giving teams a unified, queryable view of their infrastructure, services, and resources.
Team
A group of users in Port, used for ownership assignment and RBAC. Teams in Port are also first-class entities in the catalog (a built-in blueprint), meaning they can hold properties, participate in relations, and appear in catalog views.
Workflow
Port's orchestration feature (currently in Beta) for sequencing multiple steps - actions, conditions, loops - into a multi-step automated process. Not to be confused with CI/CD "workflows" such as GitHub Actions workflows - a Port Workflow is a higher-level orchestration construct within Port itself.