diff --git a/website/docs/docs/bi-directional-contract-testing/contracts/oas.md b/website/docs/docs/bi-directional-contract-testing/contracts/oas.md
index a208fffb..17286238 100644
--- a/website/docs/docs/bi-directional-contract-testing/contracts/oas.md
+++ b/website/docs/docs/bi-directional-contract-testing/contracts/oas.md
@@ -32,4 +32,4 @@ When using the OpenAPI Specifications as a Provider Contract, you should know th
 
 - It is recommended to set `additionalProperties` to `true` on request items to align with [Postel's Law](https://en.wikipedia.org/wiki/Robustness_principle).
 - _Implementing_ a spec is not the same as being _compatible_ with a spec ([read more](https://pactflow.io/blog/contract-testing-using-json-schemas-and-open-api-part-1/)). Most tools only tell you that what you’re doing is _not incompatible_ with the spec.
-- You are responsible for ensuring sufficient OAS coverage. To highlight this point, in our [Dredd example](https://github.com/pactflow/example-bi-directional-provider-dredd), we do _not_ test the 404 case on the provider, but the consumer has a pact for it and it's tests still pass! _NOTE: We plan to address this problem in the future via our OAS Testing Tool_.
\ No newline at end of file
+- You are responsible for ensuring sufficient OAS coverage. To highlight this point, in our [Dredd example](https://github.com/pactflow/example-bi-directional-provider-dredd), we do _not_ test the 404 case on the provider, but the consumer has a pact for it and its tests still pass! _NOTE: We plan to address this problem in the future via our OAS Testing Tool_.