Programs & Contracts
A single project is a unit of delivery — a defined outcome with a start and an end. But real work doesn't stop at one deliverable. Programs keep related projects connected over time, and Contracts keep every engagement honest about scope, change, and what was promised.
Setting up a program, reviewing a change request, or checking what the contract says is all conversational. Ask Loyd: "What changed in the SOW for the Acme migration?" or "Start a follow-on project in the same program." Meet Loyd →
Programs — context that compounds
A program is a durable container for one or more related projects that share knowledge over time. When one project finishes, what it learned doesn't evaporate — it carries forward to the next one.
| Without a program | With a program |
|---|---|
| Each project starts cold and re-discovers the same context | New projects warm-start from everything earlier projects established |
| Knowledge lives in people's heads between engagements | A closeout knowledge bundle is captured automatically when a project completes |
| "What should we do next?" is a meeting | The platform suggests the next step based on what's still open |
Every project automatically belongs to a program — even a one-off is a "program of one" — so you never lose the option to build on it later.
What you get
- Warm starts. A new project inherits the relevant context, decisions, and artifacts from earlier projects in the same program.
- Automatic closeout capture. When a project completes, its outcomes are bundled into reusable knowledge for the program.
- Next-step suggestions. Based on what a project left open, MeetLoyd proposes sensible follow-on work — which you can launch as the next project in the program.
Contracts — delivery you can trust
Every engagement runs against a statement of work (SOW): the agreed scope, deliverables, and outcomes. MeetLoyd treats that SOW as a living contract and puts a change-control gate in front of any drift from it.
This matters because the most common way delivery goes wrong is silent scope creep. MeetLoyd makes scope changes explicit, decided, and recorded — so nobody is surprised at the end.
How change control works (in plain terms)
When new work comes up, MeetLoyd classifies it against the contract:
| Classification | Meaning | What happens |
|---|---|---|
| In scope | The request fits the agreed capabilities and effort | Work proceeds — no friction |
| In scope, more effort | Still within agreed capabilities, but bigger than planned | Flagged so effort/budget can be confirmed |
| Out of scope | Beyond what the contract covers | A change request is opened for a human to approve or reject before any work happens |
Approvals and rejections are decisions made by people, not the AI. The platform's job is to detect the change, classify it consistently, and keep an unforgeable record of what was decided and when.
What you get
- A versioned SOW. Every change to the agreed scope is a new, recorded version — you can always see what the contract said at any point.
- Tamper-evident history. The trail of changes and approvals is append-only and verifiable, which is exactly what auditors and procurement teams want to see.
- An advisory contract assistant. A specialised assistant can draft change-order language and flag drift early — but it never authorizes anything on its own. Humans hold the pen.
- "What we promised" clarity. At any point — and especially at closeout — you can show the customer the original commitments next to what was actually delivered.
Programs and Contracts are built for outcome-based engagements — consulting-style delivery, migrations, compliance work, managed services — where scope discipline and an audit trail are part of the value, not paperwork bolted on afterward.
How it fits together
- The program holds context across projects.
- Each project delivers against its contract (SOW).
- Change requests keep scope honest and decided by humans.
- Closeout bundles feed the next project in the program.