CGES Workflow
Implementer Workflow
Use this path when building an exporter or validator against CGES. This page is informative guidance, not a replacement for the standard.
| Guide Type | Informative workflow |
| Primary Audience | Exporter authors and validator implementers |
| Primary Contract | CGES-JSON-1.0 + CGES-CORE-1.0 for cross-team JSON interoperability |
Recommended Sequence
| Step |
What to do |
Why |
| 1 | Read standard/index.html and decide which profile(s) you are implementing. | Do not start from the schema alone. The schema does not define the full contract. |
| 2 | Implement JSON shape against schemas/cges-core-1.0.schema.json. | This catches structural issues early. |
| 3 | Implement semantic checks from conformance/cges-core-1.0.rules.md. | Refdes uniqueness, count equality, and connection integrity are not enforceable by schema alone. |
| 4 | Use the relevant exporter guide if your source tool is covered. | Source mapping is informative and tool-specific. It should not leak back into the core contract. |
| 5 | Run the published vectors in conformance/cges-core-1.0.vectors.json. | Vectors are the fastest way to catch drift between prose intent and implementation behavior. |
| 6 | Declare claims only after both validation phases pass. | CGES-JSON-1.0 without semantic conformance is not enough for cross-team interoperability. |
What To Ship
| Artifact |
Expectation |
| Exporter output | Profile-compliant payload with deterministic ordering and documented fallbacks. |
| Validation evidence | Schema pass + semantic rules pass + executed vector set. |
| Claim string | Profile, source tool, exporter version, and optional effort tier. |
| Extension claims | Only declare extensions that have matching payloads and matching schema validation. |