Analysis

Build OrderURL copied

The spine for this system is: Ingestion & Parsing → Policy RAG Layer → Policy Mapping + Model Routing → Migration Execution → Human Review Gate.

Each node on the spine is a hard prerequisite for the next. Parsing must come first because nothing downstream can operate without a structured policy list. RAG must come before mapping because the mapping layer depends on retrieved candidates. Mapping and routing are a single spine node in practice — routing without mapping is pointless, and mapping without routing is incomplete. Migration execution assembles what the mapping layer produces and cannot be built or tested independently. The human review gate is the final spine node because it requires a complete migration artifact to review; building the review UX against mock data is possible but validates nothing about the real pipeline.

Three bulge nodes are unblocked by spine nodes and can run in parallel with the rest of the spine once their parent is live: model routing configuration is a bulge off policy mapping — it needs the mapping layer's policy classification output but not migration execution; progress tracker is a bulge off the human review gate — it needs the done/needs-review state that the gate produces; corpus feedback loop is also a bulge off the human review gate — it needs reviewer corrections to write back to the pgvector index.

flowchart LR
    P1["Phase 1<br/>Ingestion & Parsing<br/>source → policy list"]
    P2["Phase 2<br/>Policy RAG Layer<br/>pgvector index + retrieval"]
    P3["Phase 3<br/>Policy Mapping<br/>LLM match + confidence score"]
    P4["Phase 4<br/>Migration Execution<br/>assemble Mulesoft project"]
    P5["Phase 5<br/>Human Review Gate<br/>queue + annotation UI"]

    B1["Bulge: Model Routing Config<br/>lightweight ↔ heavyweight thresholds"]
    B2["Bulge: Progress Tracker<br/>done / needs-review dashboard"]
    B3["Bulge: Corpus Feedback Loop<br/>corrections → pgvector index"]

    P1 --> P2
    P2 --> P3
    P3 --> P4
    P4 --> P5

    P3 --> B1
    P5 --> B2
    P5 --> B3

    style P1 fill:#E3F2FD,color:#0D47A1
    style P2 fill:#E3F2FD,color:#0D47A1
    style P3 fill:#E3F2FD,color:#0D47A1
    style P4 fill:#E3F2FD,color:#0D47A1
    style P5 fill:#E3F2FD,color:#0D47A1
    style B1 fill:#E8F5E9,color:#1B5E20
    style B2 fill:#E8F5E9,color:#1B5E20
    style B3 fill:#E8F5E9,color:#1B5E20

Spine nodes (delay here delays everything): Ingestion & Parsing, Policy RAG Layer, Policy Mapping + Model Routing, Migration Execution, Human Review Gate

Bulge nodes (unblocked when parent spine node completes):

  • Model Routing Config — unblocked by Policy Mapping (needs policy classification output)
  • Progress Tracker — unblocked by Human Review Gate (needs done/needs-review state)
  • Corpus Feedback Loop — unblocked by Human Review Gate (needs reviewer corrections)
gantt
    title tibco-apigee-migration-workbench — Spine + Bulge Build Plan
    dateFormat YYYY-MM-DD
    axisFormat W%W

    section Spine
    Ingestion & Parsing         :p1, 2026-05-01, 1w
    Policy RAG Layer            :p2, after p1, 2w
    Policy Mapping + Routing    :p3, after p2, 2w
    Migration Execution         :p4, after p3, 2w
    Human Review Gate           :p5, after p4, 2w

    section Bulges (parallel)
    Model Routing Config        :b1, after p3, 1w
    Progress Tracker            :b2, after p5, 1w
    Corpus Feedback Loop        :b3, after p5, 1w

    section Validation (parallel to spine from P3)
    Contract Testing Strategy   :v1, after p2, 2w
    Test Generation + Sign-off  :v2, after p4, 2w

Parallelism rules:

  • Policy RAG Layer cannot be parallelised with Ingestion & Parsing — the index schema depends on knowing what fields the parsed policy object carries; building the index before the parser is defined means rebuilding it when the schema changes.
  • Contract Testing Strategy can run in parallel with Policy Mapping and Migration Execution — it does not depend on the generated output, only on the source API artifacts which are available from Phase 1.
  • Model Routing Config, Progress Tracker, and Corpus Feedback Loop can all run simultaneously with each other once the Human Review Gate is live — they have no dependencies on each other.
  • Do not start the cold-start migration program (first 20–30 APIs) until the Human Review Gate is operational — running migrations without a review gate means flagged items have nowhere to go and corrections are lost.