How CogniDev migrates a TIBCO project to AWS — and how you verify every line of it.

The deterministic cycle

Every migration runs through six phases. Each phase emits a signed artifact that the next phase reads. Nothing is implicit; everything is on disk and re-runnable.

1. 01
   Parse

   Read every .bwp (process), .process, .substvar (substitution variables), .xpdl, .wsdl, .xsd, adapter config, JMS destination, JDBC binding. Build a typed AST per file. Output: parse-tree.json.

2. 02
   Graph

   Resolve transitions, sub-process calls, JMS topic flows, shared resources. Build the project-wide DAG. Output: dependency-graph.json with every activity as a node and every transition / message flow as an edge.

3. 03
   Classify

   Walk the DAG and tag idiomatic shapes (linear, iterate, parallel, choice, request-reply, file-poll, claim-check, dead-letter). Tag transactional boundaries (XA, local). Output: classification.json.

4. 04
   Map

   For every node and every shape, look up the rule in the published rule library. Each rule has an ID, a version, an input schema (which BW node it accepts) and an output schema (which AWS artifact it produces). Output: rules-applied.csv — one row per node.

5. 05
   Emit

   Each rule emits its target artifact: Step Functions ASL, Lambda handler stubs, CDK / Terraform IaC, IAM policies, Amazon MQ / SQS / SNS / MSK configs, RDS schemas, JSONata mappers. Output: a complete AWS project tree.

6. 06
   Verify

   Schema-in / schema-out equivalence between source and target. Sample-message replay where source endpoints are reachable. Static analysis on the emitted code. Output: verification-report.json + the signed evidence pack.

Schema equivalence — how we prove semantic match

Every migration emits a schema-diff.json that compares the source XSD field-by-field against the target JSON Schema. This is the artifact a customer's architect reads first.

 1 {
 2   "schema": "Order",
 3   "source": { "file": "/Schemas/Order.xsd", "hash": "7e2d…" },
 4   "target": { "file": "/schemas/order.schema.json", "hash": "a91f…" },
 5   "fields": [
 6     { "path": "Order/@id",             "src": "xsd:string",   "tgt": "string",            "status": "MATCH" },
 7     { "path": "Order/Customer/Name",   "src": "xsd:string",   "tgt": "string",            "status": "MATCH" },
 8     { "path": "Order/Customer/Tier",   "src": "xsd:string",   "tgt": "string",            "status": "MATCH" },
 9     { "path": "Order/LineItems/Item[]/@sku",    "src": "xsd:string", "tgt": "string", "status": "MATCH" },
10     { "path": "Order/LineItems/Item[]/Weight",   "src": "xsd:decimal", "tgt": "number", "status": "MATCH" },
11     { "path": "Order/LineItems/Item[]/Quantity", "src": "xsd:int",     "tgt": "integer", "status": "MATCH" },
12     { "path": "Order/@createdAt",        "src": "xsd:dateTime", "tgt": "string (date-time)", "status": "MATCH_WITH_FORMAT_HINT" }
13   ],
14   "summary": { "match": 7, "format_hint": 1, "mismatch": 0, "unmapped": 0 },
15   "replay": { "samples": 12, "passed": 12, "failed": 0, "divergence_fields": [] }
16 }

MATCH_WITH_FORMAT_HINT means the values are equivalent but expressed differently (XSD xsd:dateTime → JSON Schema string with format: date-time). The replay block proves it with sample data: 12 input messages from the source side were run through both the original BW process and the generated Step Function, with field-by-field diffs of the resulting outputs. Zero divergence means the migration is semantically equivalent for the sample set; the same harness keeps running in CI after deploy.

The evidence pack — what an auditor receives

Every migration ships a signed evidence bundle. An auditor opens it and answers their own questions; no presentation needed.

• source-tree.json — every source file with hash, size, and parse status
• dependency-graph.json — the full DAG with all transitions and shared resources
• rules-applied.csv — one row per node: source_file,source_line,node_type,rule_id,rule_version,target_file,target_line
• schema-diff.json — field-by-field XSD ↔ JSON Schema match
• replay-results.json — sample-message replay with field-level divergence (zero or otherwise)
• llm-proposals.jsonl — every LLM call: prompt, response, contract-gate verdict (accepted / rejected with reason). Empty if the project had no long-tail bodies.
• human-review.md — activities flagged for human review with file, line, reason
• rule-library-manifest.json — every rule used, with version, hash, and a link to its source in the published library
• signature.sig — signature of the bundle so downstream consumers can verify integrity

A reviewer can pick any row in rules-applied.csv, open the cited rule in the manifest, open the source and target files at the cited lines, and verify with their own eyes that the rule did what it claims. That's what we mean by audit-grade.