Atlassian's JSM spec models a Java class where a document should be

Atlassian's JSM spec models a Java class where a document should be

The best bug report I have read this month is on Atlassian’s developer community, and it is about one schema in one OpenAPI document. In FormAnswer.adf schema in JSM Cloud OpenAPI spec models Jackson JsonNode internals, a developer posting as AndreasBurkard traces a failing request back to the contract. The adf property on FormAnswer, the field that carries a rich-text answer in Atlassian Document Format when you create a Jira Service Management request, references a component schema named JsonNode. That schema “is not a generic ‘any JSON value’ schema — it appears to be generated by reflecting over the Java class,” with properties like bigDecimal, booleanValue, and textValue. None of them is part of an ADF document.

This is a user’s report, not a vendor’s post, so the numbers are evidence rather than marketing. The same broken model shows up in “three unrelated generated clients,” a Java client from openapi-generator, a Dart package, and a Rust crate, “confirming this originates in the shared upstream spec.” The consequence is the part that makes it a story: a real document deserialized into that model matches no fields, so on the way back out “adf becomes {} instead of the original document,” and the API answers with a 400 and “Invalid form format.” “This is a silent failure — nothing raises a compile-time or obvious runtime error.” The proposed fix is three lines, type object with additional properties allowed. I checked Atlassian’s published spec today and the defect is still there: FormAnswer.adf points at JsonNode, which carries 36 accessor properties and forbids any others.

The catalog holds the surface and, it turns out, the same leak in a second place. The Atlassian provider page lists 186 API pages, and the operation in the report, creating a customer request, lives on the Atlassian Jira Service Management Request API, with the form fields defined by the Atlassian Jira Service Management Request Type API. The catalog’s own copy of the Jira platform contract carries a schema with the same Jackson accessor names, which suggests the reflection is a property of how these specs are produced rather than a one-off. The agentic access profile maps 2,550 operations, 1,290 of them acting.

The Kin Score is 75.1, exemplar band, with contract quality at 73.3, the highest facet on the record. That is the uncomfortable part, and it is a finding about our rubric as much as about Atlassian. A contract can be complete, typed, and well described and still be wrong in a way no linter flags, because a schema that validates is not the same as a schema that is true. The Agent Readiness score is 42.2, agent-ready, with dry-run mode lit. Every generated client and every agent reading this contract inherits the mistake, and an agent will fail the same silent way the report describes. Atlassian’s contract scores well. One schema in it describes a Java class, and three ecosystems of generated code now faithfully reproduce the error.

← Veeva scores 72.8, exemplar, on sixteen operations and a tenant no agent can reach
GitHub says Skills did not kill MCP, and its own record ships both →