Skip to content
MirrorFirm

How should an environment team scope a pilot for this workflow?

An explanation of how to narrow a first engagement to a few task families, a defined schema and agreed checks, so the pilot answers a specific question.

A good pilot answers one question. For an environment team, the usual question is whether the generated state and tasks can be loaded, run and graded in your harness, and whether they discriminate between stronger and weaker agents.

Scope it around four decisions.

**Task families.** Pick two or three, for example clean booking, booking with an amendment, and booking that should end in an exception.

**Schema.** Name the tables and fields you need and the formats you can load. Start with fewer than you think you want.

**Checks.** Agree before generation how you will judge the sample: key integrity, solvability by a reference solver, spread of outcomes and review for grounding and disclosure risk.

**Boundaries.** Decide which parts of your own environment, such as tool names, remain fixed, and which MirrorFirm should adapt to.

Commercial terms, delivery arrangements and licence scope are agreed with MirrorFirm directly. The output is generated, so the licence covers generated material and not real business records.

At the end, write down what you decided and why. That record is the basis for any larger release.

A pilot works best when it tests one decision, such as whether the generated state is usable in your harness, and nothing broader.

Audience:
Environment builders
Content type:
Explanation
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Loan booking