You already have an identity layer. You just don't know it, because it's in six places and none of them agree with each other.
Open your laptop on a Monday morning and try to answer a simple question: what is this service? Not what it does, but what it is. Who owns it. What it promises. What it depends on. What it refuses to do. You'll find yourself opening Backstage for the service catalog, then an OpenAPI spec for the contract, then Terraform for the infrastructure topology, then a CLAUDE.md for coding conventions, then an ADR folder for architectural context, then a pile of Kubernetes manifests for deployment configuration. Six tabs. Six partial answers. No single source of truth.
This is the state of identity in most engineering organizations. The information exists. It's just balkanized across tools that were never designed to compose with each other.
The tools you already have (and what they can't tell you)
Consider what Backstage gives you. Spotify built it to solve their own service catalog problem, and it has since spread to over 3,400 organizations and more than 2 million developers. It captures ownership, lifecycle stage, documentation links, and plugin-driven metadata. It is the closest thing most teams have to a service identity record.
But Backstage captures what you tell it, and what you tell it is often incomplete. 86% of Backstage users still struggle with context discovery, according to Cortex's 2024 State of Developer Productivity report. Adoption outside Spotify frequently stalls below 10% of an organization's engineering staff. The catalog entry says who owns the service and what stage it's in. It does not say what the service promises to its consumers, how it behaves under failure, or why the team chose this architecture over the alternatives.
So you open the OpenAPI spec. Now you have the API contract: endpoints, request shapes, response schemas, authentication requirements. This is precise, machine-readable, and useful. It is also radically narrow. An OpenAPI spec declares the surface area of an API. It says nothing about who owns the service behind it, what business domain it serves, what SLOs it commits to, what downstream services depend on it, or what happens when it fails. The contract describes the handshake. It does not describe the hand.
For infrastructure, you have Terraform. Your HCL files encode the topology of your system with real precision: what runs where, how resources connect, what permissions exist. Terraform knows more about your system's physical shape than most engineers on the team. But it encodes none of the why. Two services might share a VPC for good architectural reasons or because someone copy-pasted a module eighteen months ago. Terraform can't tell you which. The topology is there. The rationale is absent.
CLAUDE.md files and similar LLM instruction files capture something different: coding conventions, naming standards, review expectations, and workflow rules. This is genuinely valuable for agent-assisted development. But frontier LLMs can reliably follow roughly 150 to 200 instructions, and a CLAUDE.md is scoped to how code gets written, not what the service is, who it serves, or how it relates to the thirty other services in the platform. It captures the dialect. It does not capture the meaning.
ADRs, architecture decision records, are point-in-time snapshots of decisions. They record what was decided and why, which is exactly what Terraform and OpenAPI leave out. The problem is temporal. An ADR describes the system as it was understood on the day the decision was made. Six months of incremental changes later, the ADR is a historical document. Nothing connects it to the current state of the system. You can read every ADR in the repo and still not know whether the system currently reflects those decisions or has quietly drifted away from them.
And then there are Kubernetes manifests. For N services across 3 environments, you're looking at roughly 15N YAML files: deployments, services, ingresses, configmaps, secrets. These files define the deployment identity of each service with great specificity. They also define it in a format that is almost impossible for a human to reason about holistically. The deployment identity is real. It's just buried in YAML that no one reads end-to-end.
The gap is the problem
Each of these tools captures a real facet of service identity. Ownership. Contracts. Topology. Conventions. Rationale. Deployment shape. Individually, they work. The problem is what lives in the spaces between them.
Who is responsible for keeping the Backstage catalog entry consistent with the Terraform topology? When the OpenAPI spec adds a new endpoint, does the ADR folder get a new record explaining why? When a Kubernetes manifest changes the resource limits, does anyone update the SLO that downstream consumers depend on? When the CLAUDE.md adds a new convention, does anyone check whether it contradicts an architectural decision from two years ago?
The answer, in almost every organization, is nobody. The gaps between tools are unowned territory.
The average knowledge worker switches between applications over a thousand times per day, maintaining mental models for fifteen or more CLI tools and domain-specific languages. These aren't just productivity losses. They're identity losses. Every context switch is a moment where the holistic picture of a service dissolves and gets reassembled, imperfectly, in someone's head.
The Cortex 2024 report found that 40% of developers cite time spent gathering project context as their top productivity blocker. Teams that have adopted internal developer portals report context-finding impediments at 24%, compared to 48% for teams without one. That's a meaningful improvement, but it still means one in four developers on portal-equipped teams is burning time reconstructing context that should be declarative and available.
The fragmentation creates a specific failure mode that gets worse with agents. A human developer doing context assembly can at least recognize when pieces don't fit together. They notice that the Backstage entry says "production-ready" while the Terraform config still points to a staging database. They catch the contradiction because they have the full picture in their head, however briefly.
An agent given a CLAUDE.md and an OpenAPI spec will produce code that is perfectly consistent with both and potentially wrong for the system as a whole. It won't notice that the deployment topology constrains what the API can actually promise. It won't cross-reference the ADR that explains why a particular pattern was rejected two quarters ago. It will operate within its context window with high fidelity and zero peripheral vision.
What a unified identity layer actually looks like
The answer is not another tool bolted onto the existing stack. It is not a dashboard that aggregates the other six tools into a seventh tab. The answer is a single, machine-readable declaration that captures what each tool currently captures in isolation, fills the gaps between them, and stays connected to the living system.
A unified identity layer for a service would declare ownership (who is responsible), contracts (what the service promises to consumers and what it expects from dependencies), topology (where it runs and how it connects), conventions (how code is written and reviewed), rationale (why this architecture, why these tradeoffs), deployment shape (how it gets to production), and boundaries (what this service explicitly does not do). All in one place. All in a format that humans can read and machines can enforce.
This is not a fantasy specification. It's what you already have, consolidated. The information exists across your Backstage entries, OpenAPI specs, Terraform modules, CLAUDE.md files, ADRs, and Kubernetes manifests. The work is not generating new information. The work is giving it a shared schema and a single address.
When a unified declaration exists, agents can operate with full context rather than partial views. CI pipelines can validate changes against the complete identity, not just the code. Teams can review a service's identity the way they review a pull request: as a diff against the previous state, with every change visible and every contradiction flagged.
The gap between having an IDP and not having one already cuts context-finding problems nearly in half. A unified identity layer, one that connects what IDPs capture with what they currently miss, closes the rest of that gap.
Monday morning
Pick one service. The one that generates the most on-call pages, or the one your agents interact with most frequently.
Audit what you already have. Open every tool that knows something about this service: catalog entry, API spec, infrastructure config, LLM instructions, decision records, deployment manifests. Write down what each one captures. Then write down what falls through the cracks.
You will find ownership declared in Backstage but not enforced anywhere. Contracts in OpenAPI with no connection to the SLOs in the monitoring system. Infrastructure topology in Terraform with no link to the business rationale in the ADRs. Coding conventions in CLAUDE.md with no awareness of the service boundaries in the catalog. Deployment identity in Kubernetes with no relationship to the API contract it serves.
Each gap is a place where context gets lost, where agents operate blind, and where the next incident will start with "but the spec didn't say anything about that."
You have the pieces. The work now is making them whole.
Half an identity layer is worse than none, because it creates the illusion of coverage. We are building tooling that turns fragmented identity into a single, verifiable declaration.