Bỏ qua

Agent authoring reference

Warning

The current page still doesn't have a translation for this language.

But you can help translating it: Contributing.

See also the generated source capabilities, targets and exporters, client operations, and structural operations.

Assembly workflow

1. Capture the requested model

Capture the requested products, cardinalities, relationships, output destinations, and acceptance criteria before selecting generators or syntax.

Why: The caller's data contract must drive the model; a plausible descriptor is not enough.

Model paths: document.root, expectations

Rules: validation

Canonical BuildRequestV4 starter:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
{
  "version": "4.0",
  "document": {
    "version": "1",
    "root": {
      "kind": "setup",
      "properties": {},
      "content": null,
      "children": [
        {
          "kind": "generate",
          "properties": {
            "name": "starter_records",
            "count": "1"
          },
          "content": null,
          "children": [
            {
              "kind": "key",
              "properties": {
                "name": "value",
                "constant": "example"
              },
              "content": null,
              "children": []
            }
          ]
        }
      ]
    }
  },
  "expectations": [
    {
      "kind": "exact_count",
      "subject": {
        "kind": "product",
        "product": "starter_records"
      },
      "count": 1
    },
    {
      "kind": "fixed_value",
      "subject": {
        "kind": "product",
        "product": "starter_records"
      },
      "field": "value",
      "value": "example"
    }
  ],
  "environment_bindings": [],
  "descriptor_path": "model.xml",
  "max_count": 1,
  "sample_rows": 1
}

2. Choose the execution basis

Choose one registered DM JSON node per top-level workflow: generate for generation or a source-backed transformation, iterate for source traversal without a target, or operate for one declared operation.

Why: The registered element owns execution semantics; DM JSON does not invent a parallel product mode.

Model paths: document.root.children[].kind, document.root.children[].properties.count, document.root.children[].properties.traversal_count, document.root.children[].properties.traversal_limit

Rules: limit

3. Configure a bounded source

For a source-backed node, choose one catalogued source family, set traversal_count or traversal_limit, then select only a distribution and source options supported by that family.

Why: Source families have different ordering, uniqueness, cyclic, selector, and parallelism contracts.

Model paths: document.root.children[].properties.source, document.root.children[].properties.traversal_count, document.root.children[].properties.traversal_limit, expectations[].exact_count

Rules: limit

4. Assemble fields in dependency order

Declare key, nestedKey, and reference nodes in dependency order. Use direct generator, entity, range, values, constant, reference, or script properties accepted by the selected registered node. Before a dependent nested script, inspect the selected variable or key element's scope contract; do not assume that an unqualified binding name denotes the current nested row.

Why: Earlier fields and bindings form the expression context available to later scripted fields.

Model paths: document.root.children[].children, expectations

Rules:

5. Model value lineage between products

Nest a one-level generate node beneath its immediate parent and copy the parent identifier with a script property using parent.<field> or this.parent.<field>. When later top-level workflows need several values from one generated context, write that context to memstore and consume it with a bounded source product; use output_shape='authored_fields' when its target requires a narrower row shape.

Why: Immediate-parent scope and explicit in-run memstore lineage keep product graphs reviewable without recreating shared identifiers independently.

Model paths: document.root.children[].children, document.root.children[].children[].properties.script, document.root.children[].properties.source, document.root.children[].properties.target, document.root.children[].properties.converter

Rules: foreign_key

6. Select targets and side effects

Choose target properties only from the target capability catalog. Keep connection facts outside the DM JSON document and bind only environment identity plus family in BuildRequestV4.

Why: Targets define externally visible side effects and therefore change task intent.

Model paths: document.root.children[].properties.target, document.root.children[].properties.export_uri

Rules: side_effect

7. State acceptance expectations

Translate caller-visible invariants into explicit expectations for counts, uniqueness, foreign keys, allowed values, ranges, and row conditions.

Why: Expectations prove that generated output preserves intent instead of merely compiling.

Model paths: expectations

Rules: exact_count, per_parent_count, unique, foreign_key, allowed_values, range, row_condition

Compiler-validated Authoring pattern:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
{
  "version": "4.0",
  "document": {
    "version": "1",
    "root": {
      "kind": "setup",
      "properties": {
        "rng_seed": 42117
      },
      "content": null,
      "children": [
        {
          "kind": "database",
          "properties": {
            "id": "fixture-db"
          },
          "content": null,
          "children": []
        },
        {
          "kind": "generate",
          "properties": {
            "name": "state_created",
            "count": "1",
            "target": "fixture-db",
            "target_entity": "state_log"
          },
          "content": null,
          "children": [
            {
              "kind": "key",
              "properties": {
                "name": "record_id",
                "constant": "record-001"
              },
              "content": null,
              "children": []
            },
            {
              "kind": "key",
              "properties": {
                "name": "state",
                "constant": "CREATED"
              },
              "content": null,
              "children": []
            }
          ]
        },
        {
          "kind": "generate",
          "properties": {
            "name": "state_processed",
            "count": "1",
            "target": "fixture-db",
            "target_entity": "state_log"
          },
          "content": null,
          "children": [
            {
              "kind": "key",
              "properties": {
                "name": "record_id",
                "constant": "record-002"
              },
              "content": null,
              "children": []
            },
            {
              "kind": "key",
              "properties": {
                "name": "state",
                "constant": "PROCESSED"
              },
              "content": null,
              "children": []
            }
          ]
        },
        {
          "kind": "generate",
          "properties": {
            "name": "state_archived",
            "count": "1",
            "target": "fixture-db",
            "target_entity": "state_log"
          },
          "content": null,
          "children": [
            {
              "kind": "key",
              "properties": {
                "name": "record_id",
                "constant": "record-003"
              },
              "content": null,
              "children": []
            },
            {
              "kind": "key",
              "properties": {
                "name": "state",
                "constant": "ARCHIVED"
              },
              "content": null,
              "children": []
            }
          ]
        }
      ]
    }
  },
  "expectations": [
    {
      "kind": "exact_count",
      "subject": {
        "kind": "declared_sink",
        "sink": {
          "kind": "database",
          "environment": "fixture-db",
          "entity": "state_log"
        }
      },
      "count": 3
    },
    {
      "kind": "unique",
      "subject": {
        "kind": "declared_sink",
        "sink": {
          "kind": "database",
          "environment": "fixture-db",
          "entity": "state_log"
        }
      },
      "field": "record_id"
    },
    {
      "kind": "allowed_values",
      "subject": {
        "kind": "declared_sink",
        "sink": {
          "kind": "database",
          "environment": "fixture-db",
          "entity": "state_log"
        }
      },
      "field": "state",
      "values": [
        "CREATED",
        "PROCESSED",
        "ARCHIVED"
      ]
    },
    {
      "kind": "unique",
      "subject": {
        "kind": "declared_sink",
        "sink": {
          "kind": "database",
          "environment": "fixture-db",
          "entity": "state_log"
        }
      },
      "field": "state"
    }
  ],
  "environment_bindings": [
    {
      "environment": "fixture-db",
      "family": "database"
    }
  ],
  "descriptor_path": "model.xml",
  "max_count": 3,
  "sample_rows": 1
}

8. Validate, compile, and prove

Validate DmJsonDocumentV1, compile it with the EE codec, validate the exact XML, then run bounded evidence checks before returning ReadyBuild.

Why: Each projection catches a different failure class; successful JSON validation alone is insufficient.

Model paths: version, document, expectations, max_count, sample_rows

Rules: validation, limit, side_effect

Complete assembly examples

Assemble a deterministic flat product

Why: Start here for one bounded product with identity and explicit value constraints.

Key decisions:

  • A seeded shuffled integer range provides bounded unique identifiers.
  • Field roles communicate identity separately from the value-generation strategy.
  • Expectations restate count, uniqueness, vocabulary, and range as executable intent.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "records",
          "count": "5",
          "target": "LogExporter"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "type": "int",
              "min": "1",
              "max": "99",
              "distribution": "shuffle"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "category",
              "values": "('A', 'B', 'C')"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "score",
              "type": "int",
              "min": "10",
              "max": "20"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
<setup rngSeed="42">
    <generate name="records" count="5" target="LogExporter">
        <key name="id" type="int" min="1" max="99" distribution="shuffle"/>
        <key name="category" values="('A', 'B', 'C')"/>
        <key name="score" type="int" min="10" max="20"/>
    </generate>
</setup>

Rules: exact_count, unique, allowed_values, range

Combine complementary field strategies

Why: Use this pattern when one product mixes IDs, weighted categories, patterns, ranges, and constants.

Key decisions:

  • Each field selects exactly one value owner.
  • Weighted values express business frequency without hiding it in a script.
  • Patterns describe lexical shape while decimal ranges preserve numeric intent.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "tickets",
          "count": "10"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "type": "int",
              "min": "1",
              "max": "999",
              "distribution": "shuffle"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "priority",
              "values": "('low', 'medium', 'high')",
              "weights": "(0.6, 0.3, 0.1)"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "code",
              "pattern": "TCK-[0-9]{4}"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "handling_fee",
              "type": "float",
              "min": "0.5",
              "max": "9.99"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "channel",
              "constant": "web"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
8
9
<setup rngSeed="42">
    <generate name="tickets" count="10">
        <key name="id" type="int" min="1" max="999" distribution="shuffle"/>
        <key name="priority" values="('low', 'medium', 'high')" weights="(0.6, 0.3, 0.1)"/>
        <key name="code" pattern="TCK-[0-9]{4}"/>
        <key name="handling_fee" type="float" min="0.5" max="9.99"/>
        <key name="channel" constant="web"/>
    </generate>
</setup>

Rules: unique, allowed_values, range

Assemble a parent-child product graph

Why: Use for one-level child rows whose foreign key must reference each immediate parent.

Key decisions:

  • The child is nested under the parent, so its count is per parent.
  • parent.id copies the immediate parent key into the child row.
  • The foreign_key role and expectations make relationship intent independently testable.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "customers",
          "count": "4"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "type": "int",
              "min": "1",
              "max": "99",
              "distribution": "shuffle"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "region",
              "values": "('north', 'south', 'east', 'west')"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "generate",
            "properties": {
              "name": "orders",
              "count": "2"
            },
            "content": null,
            "children": [
              {
                "kind": "key",
                "properties": {
                  "name": "customer_id",
                  "script": "parent.id"
                },
                "content": null,
                "children": []
              },
              {
                "kind": "key",
                "properties": {
                  "name": "amount",
                  "type": "float",
                  "min": "10",
                  "max": "500"
                },
                "content": null,
                "children": []
              }
            ]
          }
        ]
      }
    ]
  }
}

Compiled DSL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
<setup rngSeed="42">
    <generate name="customers" count="4">
        <key name="id" type="int" min="1" max="99" distribution="shuffle"/>
        <key name="region" values="('north', 'south', 'east', 'west')"/>
        <generate name="orders" count="2">
            <key name="customer_id" script="parent.id"/>
            <key name="amount" type="float" min="10" max="500"/>
        </generate>
    </generate>
</setup>

Rules: per_parent_count, foreign_key

Chain generated and source products through memstore

Why: Use for bounded multi-stage assembly when a later product consumes an earlier product in the same run.

Key decisions:

  • The producer target id and consumer source id are identical.
  • The source product is explicitly bounded and copies source fields through this..
  • The default output shape preserves source fields; output_shape='authored_fields' emits exactly the consumer's declared field outputs for a narrower target.
  • Cross-product roles and expectations preserve lineage and value constraints.

Authoring model:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "users",
          "count": "5",
          "target": "mem",
          "target_entity": "users_memstore"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "type": "int",
              "min": "100",
              "max": "999",
              "distribution": "shuffle"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "region",
              "values": "('eu', 'us', 'apac')"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "credit_limit",
              "type": "int",
              "min": "100",
              "max": "1000"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "internal_note",
              "constant": "producer-only"
            },
            "content": null,
            "children": []
          }
        ]
      },
      {
        "kind": "generate",
        "properties": {
          "name": "user_audit",
          "source": "memstore://users_memstore",
          "distribution": "ordered",
          "converter": "ProjectFields('id', 'region', 'credit_limit')",
          "traversal_count": 5
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "region",
              "script": "this.region"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "credit_limit",
              "script": "this.credit_limit"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
<setup rngSeed="42">
    <generate name="users" count="5" target="mem" targetEntity="users_memstore">
        <key name="id" type="int" min="100" max="999" distribution="shuffle"/>
        <key name="region" values="('eu', 'us', 'apac')"/>
        <key name="credit_limit" type="int" min="100" max="1000"/>
        <key name="internal_note" constant="producer-only"/>
    </generate>
    <generate name="user_audit" source="memstore://users_memstore" distribution="ordered" converter="ProjectFields('id', 'region', 'credit_limit')" count="5">
        <key name="id" script="this.id"/>
        <key name="region" script="this.region"/>
        <key name="credit_limit" script="this.credit_limit"/>
    </generate>
</setup>

Rules: exact_count, foreign_key

Place constraints at the correct execution boundary

Why: Use when source rows must be checked before mapping and completed rows must be checked or assigned before export.

Key decisions:

  • source_constraints inspect loaded rows before fields execute.
  • target_constraints inspect or assign the completed generated row before export.
  • General expectations remain separate evidence checks over captured results.

Authoring model:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "source_rows",
          "count": "4",
          "target": "mem",
          "target_entity": "source_rows_mem"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "region",
              "values": "('EU', 'US')"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "score",
              "type": "int",
              "min": "1",
              "max": "100"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "review_status",
              "constant": "clear"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "targetConstraints",
            "properties": {
              "if_rule": "score != 50",
              "require_rule": "review_status = 'required'"
            },
            "content": null,
            "children": []
          }
        ]
      },
      {
        "kind": "generate",
        "properties": {
          "name": "eu_rows",
          "source": "memstore://source_rows_mem",
          "distribution": "ordered",
          "traversal_count": 4
        },
        "content": null,
        "children": [
          {
            "kind": "sourceConstraints",
            "properties": {
              "if_rule": "region == 'EU'",
              "require_rule": "score != 0"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "region",
              "script": "this.region"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "score",
              "script": "this.score"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "review_status",
              "script": "this.review_status"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<setup rngSeed="42">
    <generate name="source_rows" count="4" target="mem" targetEntity="source_rows_mem">
        <key name="region" values="('EU', 'US')"/>
        <key name="score" type="int" min="1" max="100"/>
        <key name="review_status" constant="clear"/>
        <targetConstraints if="score != 50" require="review_status = 'required'"/>
    </generate>
    <generate name="eu_rows" source="memstore://source_rows_mem" distribution="ordered" count="4">
        <sourceConstraints if="region == 'EU'" require="score != 0"/>
        <key name="region" script="this.region"/>
        <key name="score" script="this.score"/>
        <key name="review_status" script="this.review_status"/>
    </generate>
</setup>

Rules: exact_count, range

Assemble deterministic time-series rows

Why: Use when start, end, interval, and series count own cardinality instead of a fixed row count.

Key decisions:

  • The half-open window and interval derive ticks per series.
  • ts.now, ts.step, and ts.series expose iterator state to script fields.
  • The timestamp role identifies observation time; explicit expectations verify derived cardinality and values.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "readings",
          "count": "2",
          "start": "2026-01-01T00:00:00Z",
          "end": "2026-01-01T06:00:00Z",
          "interval": "PT1H"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "observed_at",
              "script": "ts.now.isoformat()"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "series_id",
              "script": "f'sensor-{ts.series}'"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "step",
              "script": "ts.step"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "sensor",
              "values": "('temp', 'humidity')"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "value",
              "type": "float",
              "min": "0",
              "max": "100"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
8
9
<setup rngSeed="42">
    <generate name="readings" count="2" start="2026-01-01T00:00:00Z" end="2026-01-01T06:00:00Z" interval="PT1H">
        <key name="observed_at" script="ts.now.isoformat()"/>
        <key name="series_id" script="f'sensor-{ts.series}'"/>
        <key name="step" script="ts.step"/>
        <key name="sensor" values="('temp', 'humidity')"/>
        <key name="value" type="float" min="0" max="100"/>
    </generate>
</setup>

Rules: exact_count, allowed_values, range

Combine the remaining field intents

Why: Use this bounded project to choose between registered generators, entity attributes, length-only strings, correlated references, and nested structured lists.

Key decisions:

  • A generator owns a domain-specific synthetic value while an entity binding keeps correlated entity state.
  • A reference maps two values from the same selected source row instead of sampling them independently.
  • A nested_list owns a bounded repeated object shape inside each profile.
data/customers.wgt.ent.csv
1
2
3
id|country|weight
100|DE|1
200|FR|1

Authoring model:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42
    },
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "profiles",
          "count": "2"
        },
        "content": null,
        "children": [
          {
            "kind": "variable",
            "properties": {
              "name": "_ent_person",
              "entity": "Person"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "generator": "UUIDGenerator"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "given_name",
              "script": "_ent_person.given_name"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "note",
              "type": "string",
              "min_length": 5,
              "max_length": 12
            },
            "content": null,
            "children": []
          },
          {
            "kind": "reference",
            "properties": {
              "name": "customer",
              "source": "data/customers.wgt.ent.csv",
              "weight_column": "weight",
              "distribution": "ordered"
            },
            "content": null,
            "children": [
              {
                "kind": "field",
                "properties": {
                  "target": "customer_id",
                  "source_key": "id"
                },
                "content": null,
                "children": []
              },
              {
                "kind": "field",
                "properties": {
                  "target": "customer_country",
                  "source_key": "country"
                },
                "content": null,
                "children": []
              }
            ]
          },
          {
            "kind": "nestedKey",
            "properties": {
              "name": "risk",
              "type": "dict"
            },
            "content": null,
            "children": [
              {
                "kind": "key",
                "properties": {
                  "name": "level",
                  "constant": "LOW"
                },
                "content": null,
                "children": []
              }
            ]
          },
          {
            "kind": "nestedKey",
            "properties": {
              "name": "contacts",
              "type": "list",
              "min_count": 1,
              "max_count": 1
            },
            "content": null,
            "children": [
              {
                "kind": "key",
                "properties": {
                  "name": "type",
                  "constant": "email"
                },
                "content": null,
                "children": []
              },
              {
                "kind": "key",
                "properties": {
                  "name": "address",
                  "pattern": "[a-z]{5}@example\\.com"
                },
                "content": null,
                "children": []
              }
            ]
          }
        ]
      }
    ]
  }
}

Compiled DSL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
<setup rngSeed="42">
    <generate name="profiles" count="2">
        <variable name="_ent_person" entity="Person"/>
        <key name="id" generator="UUIDGenerator"/>
        <key name="given_name" script="_ent_person.given_name"/>
        <key name="note" type="string" minLength="5" maxLength="12"/>
        <reference name="customer" source="data/customers.wgt.ent.csv" weightColumn="weight" distribution="ordered">
            <field target="customer_id" sourceKey="id"/>
            <field target="customer_country" sourceKey="country"/>
        </reference>
        <nestedKey name="risk" type="dict">
            <key name="level" constant="LOW"/>
        </nestedKey>
        <nestedKey name="contacts" type="list" minCount="1" maxCount="1">
            <key name="type" constant="email"/>
            <key name="address" pattern="[a-z]{5}@example\.com"/>
        </nestedKey>
    </generate>
</setup>

Rules: unique

Assure a finite heterogeneous fixture across one declared sink

Why: Use only for a small finite fixture whose intentionally different rows cannot be expressed by one declarative generated product.

Key decisions:

  • Prefer one product when its row variation is already declarative.
  • Use singleton contributors only for a finite set of intentionally different fixture rows.
  • Count and uniqueness use the declared-sink row union, not one singleton product.
  • The bounded proof does not claim event order or the state of an external database.

Authoring model:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {
      "rng_seed": 42117
    },
    "content": null,
    "children": [
      {
        "kind": "database",
        "properties": {
          "id": "fixture-db"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "state_created",
          "count": "1",
          "target": "fixture-db",
          "target_entity": "state_log"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "record_id",
              "constant": "record-001"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "state",
              "constant": "CREATED"
            },
            "content": null,
            "children": []
          }
        ]
      },
      {
        "kind": "generate",
        "properties": {
          "name": "state_processed",
          "count": "1",
          "target": "fixture-db",
          "target_entity": "state_log"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "record_id",
              "constant": "record-002"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "state",
              "constant": "PROCESSED"
            },
            "content": null,
            "children": []
          }
        ]
      },
      {
        "kind": "generate",
        "properties": {
          "name": "state_archived",
          "count": "1",
          "target": "fixture-db",
          "target_entity": "state_log"
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "record_id",
              "constant": "record-003"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "state",
              "constant": "ARCHIVED"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
<setup rngSeed="42117">
    <database id="fixture-db"/>
    <generate name="state_created" count="1" target="fixture-db" targetEntity="state_log">
        <key name="record_id" constant="record-001"/>
        <key name="state" constant="CREATED"/>
    </generate>
    <generate name="state_processed" count="1" target="fixture-db" targetEntity="state_log">
        <key name="record_id" constant="record-002"/>
        <key name="state" constant="PROCESSED"/>
    </generate>
    <generate name="state_archived" count="1" target="fixture-db" targetEntity="state_log">
        <key name="record_id" constant="record-003"/>
        <key name="state" constant="ARCHIVED"/>
    </generate>
</setup>

Rules: exact_count, unique, allowed_values, unassured_multi_contributor_sink

Transform a project file into an artifact

Why: Use for a bounded project-relative input whose transformed rows must become a file artifact.

Key decisions:

  • The .ent.csv suffix declares a structured project-file source.
  • Ordered selection and an explicit count make the read bounded and reproducible.
  • The CSV target creates a Platform-managed artifact without hard-coding a storage path.
data/orders.ent.csv
1
2
3
id|status
1|new
2|paid

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "orders_export",
          "source": "file://data/orders.ent.csv",
          "target": "CSV",
          "distribution": "ordered",
          "traversal_count": 2
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "status",
              "script": "this.status"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
<setup>
    <generate name="orders_export" source="file://data/orders.ent.csv" target="CSV" distribution="ordered" count="2">
        <key name="id" script="this.id"/>
        <key name="status" script="this.status"/>
    </generate>
</setup>

Rules: exact_count

Execute one explicit database operation

Why: Use operation only for a reviewed source-free clear or MongoDB drop statement.

Key decisions:

  • The operation product has no fields or row count because it represents one statement.
  • The target identifies the configured client, physical entity, and allowed operation verb.
  • The external database profile owns credentials and side-effect verification.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "database",
        "properties": {
          "id": "orders_db"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "clear_orders",
          "target": "orders_db.clear",
          "target_entity": "orders"
        },
        "content": null,
        "children": []
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
<setup>
    <database id="orders_db"/>
    <generate name="clear_orders" target="orders_db.clear" targetEntity="orders"/>
</setup>

Rules: side_effect

Copy a bounded relational selection

Why: Use when rows move from one configured relational source into an explicit database target.

Key decisions:

  • Source and target client ids stay separate so read and write authority remains explicit.
  • Ordered selection plus count owns the bounded input contract.
  • Acceptance checks the captured transformed rows independently of the database write.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "database",
        "properties": {
          "id": "source_db"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "database",
        "properties": {
          "id": "target_db"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "orders_copy",
          "source": "database://source_db",
          "target": "target_db",
          "distribution": "ordered",
          "source_entity": "orders",
          "target_entity": "orders_copy",
          "traversal_count": 5
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "status",
              "script": "this.status"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
8
<setup>
    <database id="source_db"/>
    <database id="target_db"/>
    <generate name="orders_copy" source="database://source_db" target="target_db" distribution="ordered" sourceEntity="orders" targetEntity="orders_copy" count="5">
        <key name="id" script="this.id"/>
        <key name="status" script="this.status"/>
    </generate>
</setup>

Rules: exact_count

Project a bounded MongoDB collection

Why: Use for a bounded collection read whose selected fields are written to another collection.

Key decisions:

  • The MongoDB source names a collection and an ordered bounded traversal.
  • The target collection is static and the insert operation is explicit.
  • Client configuration and cleanup belong to the MongoDB CI profile, not the Authoring model.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "mongodb",
        "properties": {
          "id": "mongo_in"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "mongodb",
        "properties": {
          "id": "mongo_out"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "customer_projection",
          "source": "mongodb://mongo_in",
          "target": "mongo_out",
          "distribution": "ordered",
          "source_entity": "customers",
          "target_entity": "customer_projection",
          "traversal_count": 5
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "segment",
              "script": "this.segment"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
8
<setup>
    <mongodb id="mongo_in"/>
    <mongodb id="mongo_out"/>
    <generate name="customer_projection" source="mongodb://mongo_in" target="mongo_out" distribution="ordered" sourceEntity="customers" targetEntity="customer_projection" count="5">
        <key name="id" script="this.id"/>
        <key name="segment" script="this.segment"/>
    </generate>
</setup>

Rules: exact_count

Forward a bounded Kafka selection

Why: Use when a finite topic selection must be transformed and published through another exporter.

Key decisions:

  • Importer and exporter ids remain distinct contracts.
  • Count bounds the consume operation; Kafka ordering remains partition-local.
  • The Kafka CI profile owns topics, broker addresses, and consumer groups.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "kafka-importer",
        "properties": {
          "id": "orders_in",
          "topic": "orders.created"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "kafka-exporter",
        "properties": {
          "id": "orders_out",
          "topic": "orders.generated"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "orders_forwarded",
          "source": "kafka://orders_in",
          "target": "orders_out",
          "distribution": "ordered",
          "traversal_count": 10
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "payload",
              "script": "this.payload"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
8
<setup>
    <kafka-importer id="orders_in" topic="orders.created"/>
    <kafka-exporter id="orders_out" topic="orders.generated"/>
    <generate name="orders_forwarded" source="kafka://orders_in" target="orders_out" distribution="ordered" count="10">
        <key name="id" script="this.id"/>
        <key name="payload" script="this.payload"/>
    </generate>
</setup>

Rules: exact_count

Forward a bounded RabbitMQ queue

Why: Use for count-bounded FIFO/SP queue consumption followed by confirmed publication.

Key decisions:

  • Ordered consumption deliberately selects one worker to preserve FIFO.
  • Count owns the upper bound while an idle queue may end the read earlier.
  • Queue topology remains broker-managed and the exporter waits for confirms.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "rabbitmq-importer",
        "properties": {
          "id": "orders_in",
          "queue": "orders.created"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "rabbitmq-exporter",
        "properties": {
          "id": "orders_out",
          "exchange": "orders",
          "routing_key": "orders.generated"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "orders_forwarded",
          "source": "rabbitmq://orders_in",
          "target": "orders_out",
          "distribution": "ordered",
          "traversal_count": 10
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "payload",
              "script": "this.payload"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
8
<setup>
    <rabbitmq-importer id="orders_in" queue="orders.created"/>
    <rabbitmq-exporter id="orders_out" exchange="orders" routing_key="orders.generated"/>
    <generate name="orders_forwarded" source="rabbitmq://orders_in" target="orders_out" distribution="ordered" count="10">
        <key name="id" script="this.id"/>
        <key name="payload" script="this.payload"/>
    </generate>
</setup>

Rules: exact_count

Consume a bounded persisted ML model

Why: Use after ml-train when a bounded product must generate records from the persisted model.

Key decisions:

  • The source model name becomes the canonical ml:// URI.
  • Count bounds sample generation and ordered is the only supported source policy.
  • Training remains an explicit prerequisite because Authoring does not invent an ml-train task.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "generate",
        "properties": {
          "name": "synthetic_customers",
          "source": "ml://customer_model",
          "target": "LogExporter",
          "distribution": "ordered",
          "traversal_count": 10
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "model_source",
              "constant": "customer_model"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
<setup>
    <generate name="synthetic_customers" source="ml://customer_model" target="LogExporter" distribution="ordered" count="10">
        <key name="model_source" constant="customer_model"/>
    </generate>
</setup>

Rules: exact_count

Transform an object into a stored artifact

Why: Use when both input and generated file artifacts live behind one object-storage client.

Key decisions:

  • The source URI addresses one object through the configured storage client.
  • The same storage id on the file target sends the generated artifact back to object storage.
  • Count bounds the read while the MinIO CI profile owns bucket setup and cleanup.

Authoring model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
{
  "version": "1",
  "root": {
    "kind": "setup",
    "properties": {},
    "content": null,
    "children": [
      {
        "kind": "object-storage",
        "properties": {
          "id": "archive"
        },
        "content": null,
        "children": []
      },
      {
        "kind": "generate",
        "properties": {
          "name": "archived_orders",
          "source": "object-storage://archive",
          "target": "JSON",
          "source_uri": "incoming/orders.csv",
          "storage_id": "archive",
          "export_uri": "processed/orders",
          "distribution": "ordered",
          "traversal_count": 5
        },
        "content": null,
        "children": [
          {
            "kind": "key",
            "properties": {
              "name": "id",
              "script": "this.id"
            },
            "content": null,
            "children": []
          },
          {
            "kind": "key",
            "properties": {
              "name": "status",
              "script": "this.status"
            },
            "content": null,
            "children": []
          }
        ]
      }
    ]
  }
}

Compiled DSL:

1
2
3
4
5
6
7
<setup>
    <object-storage id="archive"/>
    <generate name="archived_orders" source="object-storage://archive" target="JSON" sourceUri="incoming/orders.csv" storageId="archive" exportUri="processed/orders" distribution="ordered" count="5">
        <key name="id" script="this.id"/>
        <key name="status" script="this.status"/>
    </generate>
</setup>

Rules: exact_count

Authoring rules

Rule exact_count

Captured product rows must match the requested exact count.

Applies to: Explicit or derived exact-count expectations.

Remediation: Adjust the product count or generation intent to produce the requested number of rows.

Rule per_parent_count

Each parent must have the requested number of child rows.

Applies to: Explicit or derived nested relationship count expectations.

Remediation: Adjust the nested child count or relationship intent for every parent.

Rule unique

Captured values must be unique within the declared scope.

Applies to: Explicit or derived unique-field expectations.

Remediation: Use a generator and scope that cannot emit duplicate field values.

Rule foreign_key

Captured child foreign-key values must reference captured parent values.

Applies to: Explicit or derived foreign-key expectations.

Remediation: Correct the child relationship field so every key references a parent row.

Rule allowed_values

Captured field values must belong to the declared allowed set.

Applies to: Explicit or derived allowed-values expectations.

Remediation: Constrain the field generator to the declared allowed values.

Rule range

Captured numeric values must remain within the declared range.

Applies to: Explicit range expectations.

Remediation: Adjust the field range or generator bounds to fit the expectation.

Rule fixed_value

Every captured value must equal the declared fixed value.

Applies to: Explicit fixed-value expectations.

Remediation: Use a constant field or adjust the expected value to match the required model semantics.

Rule field_present

Every captured row must contain the declared field.

Applies to: Explicit required-field expectations.

Remediation: Declare and populate the required field in every row.

Rule field_absent

No captured row may contain the declared field.

Applies to: Explicit forbidden-field expectations.

Remediation: Remove the forbidden field from the product model.

Rule row_condition

Every captured row must satisfy its declared condition.

Applies to: Explicit row-condition expectations.

Remediation: Change the row condition or generation intent so every row satisfies it.

Rule unassured_multi_contributor_sink

Multiple products share a declared sink without any sink-scoped assurance.

Applies to: Supported declared insert sinks with more than one contributing product.

Remediation: Add an expectation whose subject names the declared sink and the required cross-product rule.

Rule unevaluable_sink_expectation

A declared-sink expectation requires complete bounded capture for every contributing product.

Applies to: Explicit expectations evaluated over a declared-sink row union.

Remediation: Repair bounded generation so every declared-sink contributor is captured before evaluation.

Rule limit

Bounded execution must reject unbounded or excessive expansion before execution.

Applies to: Counts, processes, nested expansion, and source-driven authoring execution.

Remediation: Use literal counts within the configured bounded maximum and one process for bounded Authoring evidence.

Rule side_effect

Dry-run execution must reject write-capable descriptor elements.

Applies to: Bounded execution with side effects disabled.

Remediation: Use run with explicit side-effect permission or remove write-capable elements.

Rule input

Authoring commands require input matching the selected typed operation.

Applies to: Application requests with missing or malformed DM JSON, build, or XML input.

Remediation: Provide the complete typed payload through the selected operation's declared input channel.

Rule validation

Authoring payloads must satisfy the versioned DM JSON or BuildRequestV4 contract.

Applies to: JSON authoring payload validation.

Remediation: Correct the reported field, discriminator, or graph reference.

Rule include

Bounded Authoring proof requires a contained, finite, literal project dependency graph.

Applies to: Dynamic, missing, escaping, cyclic, malformed, or excessive include dependencies.

Remediation: Use literal relative XML or properties paths inside the descriptor directory and keep the dependency graph within the published bounded workspace limits.

Rule unsupported_bounded_operation

Bounded Authoring proof rejects operations without a bounded evidence mode.

Applies to: Runtime operations such as model training and artifact generation.

Remediation: Remove the operation from bounded Authoring proof and validate it through its dedicated runtime workflow.

Runtime error rules