Pilot initiative · /pilot-intro is a positioning page for procurement and partners
The TAG Caribbean pilot, in plain language.
Page for the regulated buyer, the partner, and the internal sponsor reading the same document. Three audiences, one prose posture. The page lays out what the pilot is in region / buyer / scope / timebox, why Caribbean comes first and not later, and the explicit GO/NO-GO list a procurement reviewer can read deterministically. The same promises made here are verifiable against the case file at hand-off, or they do not appear here.
What this pilot is, in plain language.
Four lines cover the shape of the engagement. The named buyer, the region, the scope envelope, and the timebox each get a row — so a procurement reviewer reads the pilot as four bounded claims, not four marketing adjectives. The specifics are recorded in the case file at the Readiness Review gate.
Region — Caribbean (jurisdiction to be confirmed with the buyer).
The pilot is sequenced inside the Caribbean regulatory perimeter. The specific country / regulator set is named in the case file at the Readiness Review gate, not in marketing prose here — that is the place a procurement reviewer should look to confirm jurisdiction.
Buyer profile — one named regulated entity, one named human approver on the case file.
A single regulated buyer carries the engagement end-to-end, with a named human approver at every stage gate (Need Discovery → Readiness Review → Workflow Design → Governance Check → Software Build). The pilot is not a multi-tenant smear — it is one pilot, one buyer, one typed approver chain.
Scope envelope — one tier, one stage-gate sweep.
The pilot exercises a single CARI Forge tier across all five stage gates on a single brief. The brief itself is chosen so the workflow has a real regulator-shaped problem to argue about, not a synthetic demo. The tier to be exercised is to be confirmed with the buyer before pilot kick-off.
Timebox — bounded run, measured at hand-off.
A fixed start and a fixed end. The pilot is measured at the hand-off of the runnable Software Build plus the named-human audit-trail bundle, not at any earlier "demo" milestone. The specific dates and the hand-off deliverable list are confirmed at Readiness Review, not invented here.
Why Caribbean, why now.
Three arguments the council can defend in writing. The market context, the regulatory posture, and the sequencing reason — each named, each sourced to the case file rather than to a marketing slide. A partner or sponsor reading this section should be able to weight the same arguments before the pilot kicks off.
A regulator-shaped market that is small enough to govern and large enough to learn from.
The Caribbean regulators operate at a scale where a single named-human engagement produces a clean audit signal — the kind that teaches the council about jurisdiction-specific objection handling without the noise of a multi-tenant rollout. The market context goes into the case file at Need Discovery, not on a marketing page.
A regulatory environment where procurement reviewers expect written, deterministic claims.
Caribbean procurement reviewers tend to read positioning pages the way they read contracts — line by line, GO/NO-GO claims only. The pilot is shaped so every claim on this page is verifiable against the case file at hand-off, or it does not appear here.
A sequencing argument the council can defend in writing.
The pilot is sequenced before other regions because the Caribbean perimeter produces the cleanest first audit trail — small enough to keep the human-approver chain legible, regulator-shaped enough to keep the governance mechanics honest. The reason is recorded at the Readiness Review gate, not invented on this page.
What this pilot proves, and what it does not.
Two columns. The GO list — claims a procurement reviewer can verify against the case file at hand-off. The NO-GO list — claims this page explicitly disclaims so that a reader does not have to infer the boundary from prose. Each row is written to be read plainly by a compliance officer, not buried in a clause.
The five-stage pipeline runs end-to-end on a regulator-shaped brief.
Need Discovery → Readiness Review → Workflow Design → Governance Check → Software Build, all five gates cleared, with the named-human audit trail produced by the same run. Verifiable against the case file at hand-off.
The five-agent council argues in writing, with dissent preserved on the case file.
Risk / Demand / Growth / Competition / Money each argued, at least two opposing voices ruled on by the chairman, and unresolved objections escalated to the named human rather than silently dropped. Verifiable against the case file at hand-off.
The named human approver chain holds at every stage gate.
A single named human, a typed reason attached at each gate, an audit-trail bundle delivered alongside the Software Build. No anonymous approvals, no auto-advancing, no gate run without a signed reason on file.
Production hosting, uptime SLA, or 24/7 support.
The pilot delivers a runnable Software Build and a named-human audit-trail bundle. It does not deliver production hosting, an uptime SLA, or 24/7 support — those are outside the scaffold and are the buyer’s to operate downstream.
Multi-tenant rollout to additional Caribbean buyers.
The pilot is bounded to one named buyer and one tier. A multi-tenant rollout across additional Caribbean buyers is a separate, post-pilot decision, taken at prerogative of the regulated buyer — not implied by this pilot.
A regulatory approval, certification, or accreditation.
The pilot produces an audit trail a regulator can read. It is not itself a regulatory approval, certification, or accreditation — those remain the regulator’s to issue, on their own schedule, on their own terms.
How a TAG pilot moves through the five gates.
Five named human gates — The Oracles. Each gate has a named specialist approver, and the two bookends (Need Discovery and Software Build) can only be signed by the single named Elder Oracle. Every gate also requires at least one specialist attester on the handoff being decided. No specialist or model can move the mission past a gate without the named human in the right chair.
Gate 0 — Need Discovery
Need Oracle, signed by the named Elder Oracle
A plain-English need enters as a mission Draft. The Need Oracle and the named Elder Oracle sign gate 0; the Elder’s signature is the only one that can close a Need Discovery decision.
Gate 1 — Readiness Review
Readiness Oracle, with at least one specialist attester
Stakeholders, constraints, and intake evidence are collected across the Readiness handoff. The Readiness Oracle signs gate 1 once the typed specialist voice (Risk / Demand / Growth / Competition / Money) has signed the handoff.
Gate 2 — Workflow Design
Workflow Oracle, with at least one specialist attester
The chosen workflow, owners, and acceptance criteria are committed. The Workflow Oracle signs gate 2 against the typed specialist voice on the handoff.
Gate 3 — Governance Check
Governance Oracle, with at least one specialist attester
Compliance, procurement, and audit obligations are checked. The Governance Oracle signs gate 3, again with a typed specialist attester on the handoff being decided.
Gate 4 — Software Build
Build Oracle, signed by the named Elder Oracle
The runnable Software Build is matched against the acceptance criteria. Gate 4 closes only with the named Elder Oracle’s signature — same human who signed gate 0, by design.
Want to brief a real council on an actual pilot engagement? Request a walkthrough — an at-depth form for regulated buyers past the front-door brief. To see how the tier envelope scopes each pilot, read the pricing page. For the front of the site, return to the home page.