For procurement and compliance reviewers — what we do, and what we do not
Why this is a scaffold, not a product.
CARI Forge delivers a runnable, fully-typed Next.js Software Build from a one-line brief. Below is the explicit list of what that does not cover, and what it does. The wording is the system’s own, not marketing copy — it tracks the same promise spelled out at the FAQ’s scaffold-vs-product answer and at /pricing.
What this deliverable does NOT cover.
These five exclusions are written to be read plainly by a compliance officer, not buried in a clause. If a need here matters for your engagement, that is the conversation to have up front — not the moment to discover it at hand-off.
No production hosting.
CARI Forge does not host the Software Build. The hand-off is a runnable codebase, not a running system — there is no provisioned environment, no DNS, no certificate behind this site for what we deliver.
No uptime SLA.
There is no service-level agreement, no status page, and no on-call rotation behind the deliverable. The Software Build exists for the buyer to operate on their own infrastructure under their own terms.
No 24/7 support.
Communication runs on working-week hours, with a named human reply window. There is no always-on support desk and no tier-one triage queue — every reply is written by a named human on the case file.
No automated customer-facing login.
The way in is a one-line brief through a human-gated intake form, not a self-serve sign-up or a public sign-in flow. There is no API key issuance, no end-user account system, no public authentication surface created by the build.
No liability for downstream deployment.
Once the Software Build is received, what ships to production — and how it is operated, certified, and maintained — is the buyer’s responsibility to decide and own. CARI Forge’s responsibility ends at the Software Build receipt.
What this deliverable DOES cover (the actual promise).
These four inclusions are the shape of every run. They are produced by the system itself and recorded in the audit-trail bundle at hand-off, so the promise below is verifiable, not aspirational.
A governed pipeline.
Five stages — Need Discovery → Readiness Review → Workflow Design → Governance Check → Software Build — each with a typed deliverable and a named human approval recorded before the next stage advances.
A typed five-agent council.
Five advisor voices (Risk, Demand, Growth, Competition, Money) with opposing defaults, and a chairman who rules only after at least two opposing voices have weighed in on the same point. Dissent is written into the case file rather than averaged away, and unresolved objections are escalated to the named human, never silently dropped.
A named human approver at every gate.
Each gate decision is recorded with a named human and a typed reason. Unresolved objections are escalated to the named human, not silently dropped — and the case file makes that trail visible to the buyer at hand-off.
A runnable Next.js / TypeScript project worked end-to-end from the approved brief.
Type-safe, end-to-end, from the verbatim one-line brief in to a runnable Next.js + TypeScript Software Build out. Every line of source traced back to a named human approval at a stage gate, with the audit-trail bundle produced by the same run.
Read the same promise spelled out at the FAQ’s scaffold-vs-product answer, see how each tier scopes it at /pricing, or leave a one-line brief to start a run the way a regulated buyer actually does.