Evaluation Program
From “I have heard of OpenBean” to “I am running it in production.”
A structured 4–6 week path with named gates, named deliverables at each gate, and named exit criteria. The program is a contract: the success criteria are written down in Gate 1, the architecture is signed off in Gate 2, the pilot is bounded by the criteria in Gate 3, the production hand-off ends Gate 4, and Gate 5 is the organization running OpenBean on its own terms.
The program ends with a “yes” or a “no.” Both are valid outcomes; the contract’s value is that the “no” is a written close-out report the organization can use to inform its decision, not a quiet end-of-engagement.
Evaluations run on an evaluation license: free, 30 days, nothing restricted — full capture, full recall, your whole team, all your AI tools. If it lapses, your deployment becomes read-only and everything you captured stays readable and exportable; a purchased license reactivates the same deployment instantly, with no reinstall.
Gate 1.Discovery#discovery
Week 1 — The maintainer team and the organization's team align on the deployment target, the compliance regime, the AI tool inventory, the decision makers, the budget stage, and the success criteria for the evaluation. This is the conversation that turns an open-ended "I want to evaluate OpenBean" into a named scope with named gates.
Deliverable
A written Discovery brief, signed off by both sides, naming the deployment target, the compliance regime, the AI tool inventory, the decision makers, the budget stage, the timeline, and the success criteria for the evaluation. The brief is the contract the rest of the program runs against.
Exit condition
Both sides have signed off on the brief; the pilot scope (or production scope) is named; the maintainer team has confirmed it can support the named shape.
Next step
Move to Gate 2 (Architecture Review) if the brief names a real deployment target. Move to Gate 1.5 (Migration Assessment) first if the evaluation includes bringing existing knowledge from a wiki, Slack, or a prior AI tool.
Gate 2.Architecture Review#architecture
Week 2 — The maintainer team produces a written architecture memo for the named deployment target, working with the organization's engineering team to map OpenBean's documented properties to the organization's actual environment. The memo is the engineering team's first chance to see the deployment in their own context, not in the abstract.
Deliverable
A signed-off architecture memo: the recommended deployment topology, the security model as it lands in the named compliance regime, the migration path from the current memory surface, the named operational risks specific to the target, and the named open questions that Gate 3 needs to resolve.
Exit condition
The engineering team has the memo and has triaged the named risks into "do now" / "do later" / "won't do, and here's why."
Next step
Move to Gate 3 (Pilot Deployment) for the typical 4–6 week pilot. Move to Gate 4 (Production Deployment Support) directly if the engineering team is already confident in the memo and the deployment is well-understood.
Gate 3.Pilot Deployment#pilot
Weeks 3 – 6 (4 weeks typical) — The organization stands up a single-team, single-use-case pilot of OpenBean in their own environment, with the maintainer team attending a weekly cadence and available on a daily Slack channel. The pilot is bounded by the Gate 1 brief's success criteria.
Deliverable
A working pilot instance the pilot team uses daily; a written pilot-outcome report at the end, produced by the maintainer team, summarizing what was learned against the success criteria, what worked, what didn't, and a recommended next step.
Exit condition
The pilot has either met the named success criteria (and the next step is Gate 4) or has not (and the next step is a written close-out report the organization can use to inform its decision).
Next step
Move to Gate 4 (Production Deployment Support) on success. On close-out, the program ends with a written handoff to the organization's team, and the next step is theirs to name.
Gate 4.Production Deployment#production
Weeks 7 – 10 (4 weeks typical) — The organization stands up the first production-bound OpenBean instance, with the maintainer team walking the named owner through the operator's runbook (`doctor`, `backup`, `restore`, the upgrade sequence). The deployment ends with a one-hour hand-off to the named owner.
Deliverable
A working production instance the organization owns; a named owner who has the operator's runbook; a written hand-off summary.
Exit condition
The organization has run `npm run doctor` clean on its own instance, has executed a `backup`/`restore` drill against its own data, and can describe the upgrade sequence from memory. The engagement does not end before these three have happened on the maintainer team's watch.
Next step
Move to Gate 5 (Operational Maturity) — quarterly Health Checks and, if the organization wants, a Support engagement for the running instance.
Gate 5.Operational Maturity#maturity
Ongoing — Quarterly Health Checks and, if the organization wants, a Support engagement. The maturity gate is not a gate with a single exit; it is the program operating as designed, with the maintainer team on a quarterly cadence and the organization's team fully owning the running instance.
Deliverable
A quarterly Health Check report and, if engaged, a Support agreement with named response-time targets and named channels.
Exit condition
The engagement is renewed, expires, or is terminated; the next step is a written close-out summary.
Next step
Renewal or close-out, on the organization's terms.
