Term FF-010
Method transfer mechanism
The artifacts that survive the engagement.
Without a method transfer mechanism, a consultancy creates dependency, not capability. The client cannot operate independently because the knowledge left with the consultant.
What it is
The difference between selling hours and selling capability
Most platform engineering engagements close when the contract ends. The consultants pack up. The slides stay on a SharePoint. The design decisions that were made verbally in Zoom calls are not written down anywhere. The team that inherited the platform knows it was built with Terraform and ArgoCD, but cannot tell you why the module structure was organized the way it was, or what was evaluated before deciding against Flux.
Six months later, the team makes a decision that contradicts a trade-off the original consultants resolved. The mistake is not their fault. The knowledge was never transferred.
A method transfer mechanism is the set of artifacts that prevents this outcome. Not documentation for its own sake, but specific artifacts that encode the reasoning behind decisions and the procedures for operating the systems that were built. The test of a method transfer mechanism is whether the team can run the platform competently without the consultant being available to answer questions.
In the Foundations Framework, the method transfer mechanism is a defined output of every engagement. It is not an optional add-on. The Ascend phase documents whether the method was transferred successfully by evaluating whether the client team can score their own maturity radar, modify their own golden paths, and respond to their own incidents using the runbooks, without Clouditive involvement.
The Clouditive standard
Every Clouditive engagement produces all five artifacts below, owned by the client. When the engagement closes, Clouditive's role ends. The method continues.
The five artifacts
What a complete method transfer looks like
Architecture Decision Records
Every significant technical decision made during the engagement is documented with its context, the options considered, the decision taken, and the rationale. When the engagement ends and the lead engineer who made the decision leaves, the ADR preserves the reasoning. Without it, the next team inherits a system they cannot interrogate.
Runbooks
Documented procedures for the top incident categories. Not generic templates: runbooks specific to the client's stack, their on-call rotation, their escalation paths, and their monitoring tools. A runbook that references a tool the client does not use is not a transfer artifact. It is theater.
Golden path templates
The canonical deployment and development workflows, owned by the client and maintained in the client's infrastructure. The golden paths designed for the three persona platform user: human developer, AI agent, and hybrid collaborator. Templates the client can fork, modify, and evolve without requiring the consultant to return.
Maturity radar, re-scored
The maturity radar established at the start of the Horizon phase, re-scored at the close of the engagement. The delta between the two radars is the documented ROI of the engagement. The re-scored radar is also the starting point for the next engagement phase, or for the client team to run the next assessment independently.
DORA and AI readiness baselines
The instrumented measurement baseline the engagement established. Deployment frequency, change failure rate, lead time, MTTR, and the four AI signals. The baselines are owned by the client and exist in their tooling. When Clouditive rolls off, the measurement continues in the client's infrastructure.
Why it distinguishes a consultancy
What separates capability transfer from knowledge hoarding
A consultancy that hoards the method benefits from repeat engagements. The client cannot run the platform without them, so they return. The business model is dependency, not delivery.
A consultancy with a method transfer mechanism bets on the quality of the next problem. Clients who gained real capability from the first engagement hire the consultancy for the next one because the quality of the work was proven, not because they are trapped. The business model is trust, not lock-in.
The method transfer mechanism is also why the Foundations Framework is not published in full. The operating manual, the lexicon, the maturity rubric, and the 5x5 delivery matrix are reserved for engagement. Clients access the complete method by working with Clouditive. The public surface describes what the method produces. The artifacts transferred to the client are how those outcomes are sustained independently.
Start with a diagnostic, leave with a method
Every Foundations engagement closes with five transfer artifacts the client team owns.
Four to six weeks for the Foundations Assessment. Maturity radar. DORA baseline. 90 day roadmap.