CGES Workflow
Consumer Workflow
Use this path when consuming CGES payloads in analysis pipelines, validation services, or report generators.
| Guide Type | Informative workflow |
| Primary Audience | Consumers, validators, and downstream analysis engines |
| Preferred Input | CGES-JSON-1.0 payloads that also satisfy CGES-CORE-1.0 |
Recommended Sequence
| Step |
What to do |
Why |
| 1 | Validate payload shape against the core schema. | Reject malformed payloads before any semantic or analysis work begins. |
| 2 | Run semantic validation rules. | A schema-valid payload may still have orphan connections or inconsistent counts. |
| 3 | Treat identity.board_rev as authoritative for board identity. | metadata.schematic_revision carries source-document traceability and may legitimately differ from board identity revision. |
| 4 | Prefer canonical extension keys under analysis_modules. | Legacy aliases are transitional and should not drive downstream logic when canonical keys exist. |
| 5 | Treat CGES-MD-1.0 as a report, not a primary machine source. | The Markdown profile is human-readable output, not the canonical interchange contract. |
| 6 | Ignore unknown extension keys safely while preserving them when republishing payloads. | This avoids breaking forward compatibility. |
Quality Warnings Consumers Should Expect
| Condition |
Recommended Handling |
role or function equals unspecified | Treat as syntactically valid but semantically incomplete. |
Legacy EPSA aliases such as v_rating | Normalize to canonical keys and report a warning. |
Deprecated metadata.revision alias is present | Normalize to metadata.schematic_revision and report a deprecation warning. |
metadata.revision differs from metadata.schematic_revision | Treat as a contract violation under CGES-CORE-1.0. |
| Unnamed nets or empty strings allowed by profile | Accept structurally, but report reduced analysis quality. |