Kerno pins every response contract from your code, field by field, and catches a breaking change before it reaches your consumers.
Kerno reads the response model your framework declares and pins the assertion to it, field by field.
Every field a response returns is asserted, so a dropped, renamed or added field shows up as a failure.
The body your framework returns on failure is pinned the same way, down to the code and message fields.
Every contract is checked against what your running service returns, on your real data and dependencies.
Ids, timestamps and tokens are matched on the shape they take, so a new value stays a passing test.
Your committed contract tests replay on every pull request, and a changed shape fails the check.
Objects, arrays, nesting, and the shape every response returns.
Field types, enums, date and time formats, and numeric precision.
Presence, nullability, and the fields a consumer can rely on.
Status codes, error bodies, and the shape returned on failure.
Ids, timestamps, and tokens, matched on the shape they take.
Dropped fields, renamed keys, and shapes that change between runs.
Write a rule the way you would explain it to a new engineer, and scope it to the repositories and paths it applies to.
Agent instruction files, service READMEs and the docs in your repository shape how every contract gets pinned.
Kerno learns from each run and the feedback you give it, and carries what it learns into the checks that follow.
Got any extra questions? Reach out on our community channel and we'll be happy to help.
Kerno pins each endpoint's response and error contracts field by field, and flags any drift in structure, types, or required fields as a diff.
Kerno validates each service's response contracts and flags schema drift within that service. It does not yet generate or verify consumer-driven, Pact-style contracts across services.
No. Kerno reads the serializer or DTO in your code, so it validates the contract whether or not you publish a schema.
Kerno asserts every field a response returns, so a dropped or renamed field fails on the next run and shows up as a diff against the baseline.
Kerno reads the response model your framework declares, with dedicated handling for Django REST Framework serializers and deep symbol resolution in TypeScript, Python, Java and Kotlin.
Yes. Committed contract tests replay in CI on every pull request, and a changed response shape fails the check.