Qwen Test JSONL Schema and Usage

Date: June 28, 2026

Purpose

Summarize the JSONL format to be referenced when creating Godot code chunks with Qwen, attaching correct‑answer JSONL and incorrect‑answer JSONL to those code chunks, and performing “yes”/“no” verification. This document is not a sample‑data provision; it is a schema reference document for confirming which JSONL serves which role during testing and which fields are used for direct‑evidence judgments.

Common Rules

JSONL writes one JSON object per line.

{...}
{...}
{...}

In the test, the wrapper surrounding the table name is omitted, and the fields corresponding to the target table's columns are placed at the top level.

Good:
{"chunk_id":"...","content":"...","code_blocks":[...]}

Avoid:
{"table":"docs_chunks","payload":{"chunk_id":"..."}}

Fields that are automatically generated by the DB or written to the search index do not need to be filled in directly in the test JSONL.

Qwen direct evidence verification emphasizes “which field in the JSONL directly matches the actual string/API/pattern of the SOURCE_CODE.”

docs_chunks

Purpose

docs_chunks is a JSONL that stores official documentation explanations, tutorials, and class reference bodies in chunk units.

It is used for requesting code explanations, checking common API usage, and verifying explanations of common Godot 3/4 syntax. It serves as evidence to determine “whether this code is directly related to any official documentation explanation,” rather than the migration rules themselves.

JSONL Format

{
  "chunk_id": "text, required",
  "doc_version": "text, required",
  "source_url": "text, required",
  "source_file": "text, required",
  "source_sha256": "text, required",
  "doc_type": "text, required",
  "symbol": "text or null",
  "section_path": "array, required",
  "heading": "text or null",
  "content": "text, required",
  "code_blocks": "array, required",
  "language_tags": "array<string>",
  "godot_version_tags": "array<string>",
  "api_symbols": "array<string>",
  "token_count": "integer or null",
  "metadata": "object"
}

Direct Evidence Fields

Role in Tests

api_mapping

Purpose

api_mapping is a JSONL that records how names, class names, function names, and symbol names changed from Godot 3 to Godot 4.

It is used for simple name changes, renames, replacements, and deprecated/removed API determinations. Cases where the entire usage of a function changes are more appropriate for the label_prototypes side.

JSONL Format

{
  "mapping_id": "text, required",
  "source_api": "text, required",
  "target_api": "text or null",
  "change_type": "text, required",
  "godot_from": "text, required",
  "godot_to": "text, required",
  "confidence": "text, required",
  "evidence_chunk_ids": "array<string>",
  "match_terms": "array<string>",
  "notes": "text",
  "negative_patterns": "array<string>"
}

Direct Evidence Fields

Role in Tests

label_prototypes

Purpose

label_prototypes is a JSONL that stores examples where not only the name changes but the entire usage pattern of a function—including argument composition and call pattern—changes.

If api_mapping answers “what name changed to what,” then label_prototypes is closer to “what pattern the code should be written in.”

{
  "prototype_id": "text, required",
  "label": "text, required",
  "task_type": "text, required",
  "input_pattern": "text, required",
  "expected_finding": "text, required",
  "recommended_action": "text, required",
  "evidence_mapping_ids": "array<string>",
  "evidence_chunk_ids": "array<string>",
  "severity": "text",
  "validator_rules": "object"
}

validator_rules can have the following subfields.

{
  "required_when_seen_in_code": "array<string>",
  "before_code": "text",
  "after_code": "text",
  "reject_when_seen_in_code": "array<string>"
}

Direct Evidence Based Fields

Role in Tests

Boundaries of the Three JSONLs

Common Syntax Handling

If the syntax is the same in Godot 3 and Godot 4, it is not considered a version difference.