A platform team owns a 'Pricing' service used by a dozen other teams. Instead of leaving each consuming team to build its own anti-corruption layer against Pricing's internal model, the platform team publishes a versioned, documented API contract that Pricing commits to keeping stable, and consumers integrate against that contract instead of Pricing's internals. What pattern is the Pricing team applying, and how does it change - or reduce the need for - the ACLs each consumer would otherwise build?

## The matched pair Open-Host Service (OHS) and Published Language (PL) are a matched pair of patterns that sit on the producer side of an integration, complementing the anti-corruption layer that typically sits on the consumer side. - **An Open-Host Service** is a service that deliberately exposes a public, general-purpose interface designed for many consumers, rather than an interface shaped around whatever its own internals happen to look like or around a single consumer's specific needs. - **The Published Language** is the actual shared contract that interface speaks — a schema (OpenAPI/Swagger spec, a Protobuf/gRPC IDL, an AsyncAPI event schema, a documented JSON shape) that is explicitly versioned, documented, and treated as a promise: the producer commits to not breaking it without a deliberate, communicated versioning strategy. Mechanically, the Pricing team here builds and maintains a translation layer of its own — converting its internal domain model into the published contract — so that every consumer gets a stable, intentionally designed view instead of raw internals. That's the mirror image of a consumer-side ACL: the producer is protecting its consumers, and just as importantly protecting itself, since it can now refactor internals freely as long as the published contract holds. ## Why it exists This exists because a plain consumer-side ACL doesn't scale well when many teams depend on the same upstream: without a published contract, each of the dozen consuming teams would independently reverse-engineer Pricing's internal model, build their own translator, and re-discover the same quirks and edge cases — a lot of duplicated effort, and a lot of independent points of breakage whenever Pricing's internals shift, even in ways that shouldn't be consumer-visible. By investing once in a well-designed public contract, Pricing turns N bespoke, fragile integrations into one well-tested, explicitly maintained boundary. It's the same instinct behind ACLs — protect model integrity at integration boundaries — just applied from the producer's side of the relationship instead of the consumer's. ## Who pays for it The cost sits with the producer now. - **Design work.** Designing a good public contract is real design work, distinct from (and often harder than) just exposing whatever the internal model looks like, because it has to anticipate reasonable consumer needs without overfitting to any one of them, and it has to be versioned so internal refactors don't force a breaking change on every consumer. - **Ongoing maintenance.** There's an ongoing maintenance cost too — deprecating old contract versions responsibly, documenting changes, and resisting the pressure to bolt one-off fields onto the published language for a single demanding consumer, which erodes its generality over time. - **On the consumer side**, the benefit is real but not absolute: consumers still usually want a thin ACL translating the published language into their own domain vocabulary, both for cleanliness and as insurance, because 'published and versioned' is not the same guarantee as 'will never change in a way that surprises you' — deprecation windows lapse, and producer teams do occasionally ship breaking changes by mistake. ## Failure modes 1. **A common failure is a published language that isn't actually general** — a producer ships an 'open' API that's really shaped around its first or biggest consumer's specific needs, so every other consumer still has to build significant translation logic anyway, and the OHS/PL effort didn't pay for itself. 2. **Another is version sprawl**: without disciplined deprecation, a producer accumulates v1, v2, and v3 of the same contract live simultaneously, each with subtly different semantics, and consumers integrating at different times get inconsistent behavior — effectively re-creating the 'many models to translate against' problem the pattern was meant to solve. 3. **A third is contract drift without version bumps**: a producer changes response semantics, not just shape, without incrementing the version, silently breaking every consumer's assumptions at once, which is worse than if there'd been no published contract at all, because consumers trusted the stability promise and skipped defensive translation. ## Where it shows up A well-known real-world instance is how large platforms expose stable public APIs specifically so third-party integrators don't need to understand internal implementation details — a payments platform's versioned public API, with a dated API-version scheme and long-lived backward-compatibility guarantees, is a textbook Open-Host Service with a Published Language: the platform's internal ledger and account models are free to evolve, but the public API contract is the stable surface every integrator builds against, and versioning/deprecation policy is documented explicitly rather than leaving each integrator to reverse-engineer internals. Internally, many organizations apply the same pattern with a platform team's shared service (like the Pricing example) publishing an OpenAPI or Protobuf contract and treating it as a first-class deliverable with its own versioning and changelog, precisely to spare a dozen consuming teams from each building and maintaining a full ACL against Pricing's raw internal model.