The benefits of federating a graph with Apollo Federation and Apollo GraphOS include alleviating pain points associated with consolidating data from multiple services behind a single API endpoint, empowering independent teams to own and develop their subgraph independently, and providing the toolsets and controls for well-managed composition of the supergraph. However, despite these benefits, Apollo Federation alone does not provide all the answers when it comes to exposing subsets of the schema to third parties while hiding confidential internal fields. This is where contracts come in, which enable picking and choosing types, fields, and field arguments from the supergraph schema to create multiple different variations of the graph from a single source of truth. Contracts provide logically separated views of the supergraph, removing the need for duplication of effort across teams and preventing inconsistencies between versions. To create contract variants, you can apply the @tag directive in your schema, which allows Apollo Studio to detect fields that should be included or excluded from the new contract variant. The recommended approach is to use an "includes" filter, but both filtering approaches can be used simultaneously depending on the specific use case. Each contract variant requires a separate instance of Apollo Router, and it's possible to manage CI/CD workflows for each contract variant independently with downstream checks to control potential breaking changes. Ultimately, contracts provide a powerful way to manage multiple unrelated logical views of your graph from a single source of truth, making it easier to provide an external API securely and simply with low maintenance overhead.