Sources: data/reference/json/ccb_json_object_types.json tools/json_api/contract-inventory.schema.json tools/json_api/generate_contracts.py tools/json_api/test_generate_contracts.py src/init.cpp src/generic_factory.h tests/json_load_test.cpp doc/JSON/JSON_INHERITANCE.md doc/JSON/JSON_STYLE.md commit c663ceb2c1bd api-contract

JSON contract overview

CCB's JSON contract is not defined by one universal Schema. Runtime loaders and tests define behaviour; DynamicDataLoader registrations define top-level type dispatch; schemas, validators, and generated inventories record the subset that machines can prove. Legacy prose and data examples are leads, not overrides for those contracts.

Current machine coverage

• The JSON object-type registry indexes 190 unique registered types and 191 registration calls.
• 183 registered types have top-level instance candidates among 6,731 audited tracked JSON files.
• Seven registered types have no instance candidate; the inventory found no observed, unregistered top-level string type.
• All 190 general Schema statuses are none; the registry must not be presented as a complete game JSON Schema.
• Field contracts are unclassified for 189 types and currently partial for effect_on_condition.

These figures describe the generated inventories at commit 71f403ecea0dcf16be8fe93c661acbe2a4906cc6. They do not claim that every field, default, inheritance rule, or cross-ID reference has been classified.

How an object acquires meaning

1. The JSON parser proves that the file syntax and root container are readable.
2. A top-level object's string type enters registry dispatch.
3. Its loader or factory decides mandatory and optional fields, defaults, and errors in source.
4. Factory finalization/checks and cross-reference validation may reject it later.
5. Runtime tests prove specific behaviour and compatibility.

An occurrence in data is therefore only lexical instance evidence. A mention in legacy prose is also only lexical_only evidence. Confirm a field in the loader, tests, and validators named by the registry.

Where to start

• To determine whether a type is registered, use the generated registry.
• Before changing inherited objects, read inheritance and copy-from.
• Before submitting, follow JSON validation and evidence levels.
• For EOCs, start with EOC contracts and lifecycle.
• For a reproducible fixture, use the complete JSON/EOC mod tutorial.

If this page conflicts with an inventory, Schema, registration, or test, mark the page stale and repair it. Do not change runtime contracts merely to match prose.