Generation Contracts

sealed contract is the sealed specification that defines every generation job. It is the foundation of RadMah AI's determinism guarantee and is engine-agnostic — any engine executes against the same contract concept.

What is sealed contract?

sealed contract is a machine-readable specification that fully describes what to generate. Every generation job starts from a sealed contract. The specification is serialised deterministically, cryptographically sealed, and committed as the first artefact in every job's evidence bundle.

ℹDeterminism guarantee

Given the same sealed contract, RadMah AI produces bit-for-bit identical output on any machine at any future point. This holds across all engines.

What a sealed contract captures

At a high level, a sealed contract captures:

The data shape you want (entities, attributes, relationships)
Any domain constraints that must hold on every row
Which engine family will run and its configuration
A deterministic seed and the requested row count

You do not write sealed contract by hand. The platform fills in the details from your natural-language description, uploaded data, and account policy — then seals the spec before any generation runs.

Entity and Attribute Schema

A sealed contract can describe one or more entities (tables) with typed attributes, primary keys, nullability, and basic formatting rules. A simplified example:

Entity definition (illustrative)

{
  "entities": [
    {
      "name": "customers",
      "attributes": [
        { "name": "customer_id",    "type": "integer",  "primary_key": true, "nullable": false },
        { "name": "email",          "type": "string",   "format": "email",   "nullable": false },
        { "name": "created_at",     "type": "datetime", "nullable": false },
        { "name": "lifetime_value", "type": "float",    "min": 0.0,          "nullable": true }
      ]
    }
  ]
}

Relational Definitions

sealed contract supports foreign-key relationships between entities, with referential integrity and cardinality enforced during generation.

Relation definition (illustrative)

{
  "relations": [
    {
      "parent_entity": "customers",
      "parent_key": "customer_id",
      "child_entity": "orders",
      "child_key": "customer_id",
      "cardinality": "one_to_many",
      "min_children": 0,
      "max_children": 50
    }
  ]
}

Sealing a Contract

A sealed contract becomes immutable when it is sealed. Sealing produces a cryptographic commitment that enables deterministic replay at any future point.

Contract lifecycle

Draft state → Editable by authoring tools
Sealed state → Immutable (no modifications allowed)

# Authoring tools are rejected by the orchestrator
# if the target contract is already sealed.

Creating Contracts

Contracts can be created in several ways:

Natural language: the AI Orchestrator or Agentic Data Scientist translates a text description into a sealed contract
Programmatic: define the contract directly via the SDK or REST API
From analysis: run an analyse job on uploaded data and use the inferred schema
Replay: reuse a sealed contract by ID

✦Engine-agnostic contracts

sealed contract is engine-agnostic. The orchestrator determines the correct engine based on the contract contents, uploaded data, and user intent. You define what you want — the platform determines how to produce it.

Feasibility Check

Before any synthesis job, the platform runs a feasibility check on the Contract K — validating that the relational and domain constraints are satisfiable and that the entity graph is consistent. Infeasible contracts are rejected with a diagnostic explaining the constraint violation.