StackShift II Foundry — Three Paths
The StackShift II Foundry is a fixed-price, eight-week managed digital operations engagement for B2B teams. It offers three distinct paths — Capacity, Execution, and Accountability — each targeting a specific failure mode in digital work. Rather than evaluating StackShift II through a demo, organisations put real work through the operating model and measure what changes. The engagement costs $9,000, is fully creditable against a full StackShift II subscription signed within 30 days of completion, and concludes with a decision document and 90-day expansion plan.
Overview
The StackShift II Foundry is an eight-week, fixed-price engagement designed for B2B teams whose digital work is blocked by capacity constraints, execution friction, or accountability gaps. Rather than evaluating StackShift II through a sales deck or product demo, organisations bring a meaningful slice of real digital work — across websites, content, search, applications, or data — and test the operating model directly.
The core proposition: do not evaluate StackShift II from a deck; give it something meaningful to operate.
The Three Paths
The Foundry is structured around three distinct failure modes. Selecting a path means choosing the problem the eight-week engagement is designed to prove.
Path 01 — Capacity
The Capacity path applies when nothing is structurally broken but work is arriving faster than the team can absorb it. Product pages wait on content; search improvements wait on developers; application changes wait on IT; automation ideas remain in decks.
What StackShift II does: For eight weeks, WebriQ takes a defined slice of the backlog, converts it into managed work, executes it with the appropriate mix of specialists, automation, and agents, routes only the decisions that require the client's people, and keeps the queue moving.
What is proved: Whether an external operating layer materially increases throughput without requiring the client to scale headcount.
Path 02 — Execution
The Execution path applies when headcount is not the obvious problem. The organisation already has people, tools, agencies, and plans. Work slows at the seams: briefs become tickets; tickets wait for context; approvals live in email; dependencies emerge late; a vendor closes its piece while the overall initiative remains open.
What StackShift II does: StackShift II makes the work itself the unit of operation. Each item carries the context needed to move it — owner, dependencies, approvals, history, and evidence of completion. People, systems, and agents participate around the work instead of requiring manual coordination of every handoff.
What is proved: Whether structuring work as a self-contained operating object eliminates the coordination overhead that causes execution delays.
Path 03 — Accountability
The Accountability path applies when work may be happening everywhere but no single party owns whether the whole thing actually gets finished. Marketing owns the objective; IT owns infrastructure; developers own implementation; agencies own deliverables; SaaS vendors own their software; management owns decisions — yet completion has no clear owner.
What StackShift II does: The selected operation enters a closed accountability loop. Work has a defined intake, a state, an owner, visible dependencies, and a definition of done. Decisions are captured. Completed work carries evidence. Unresolved work cannot quietly disappear between systems, meetings, or vendors.
What is proved: Whether a closed accountability loop changes the organisation's ability to finish complex, multi-party digital initiatives.
Operating Structure
All three paths share the same eight-week commercial structure and live operating rhythm. What changes is the problem chosen to prove.
Phase Breakdown
| Phase | Duration | Activity |
|---|---|---|
| Diagnose, scope and baseline | Weeks 1–2 | Select path, define bounded workload, agree outcome and constraints, name internal operator, establish baseline for how work moves today |
| Instrument and start | Weeks 2–3 | Configure operating queue, instructions, access, and required data sources; convert workload into live work; complete first review-and-execution cycle |
| Operate | Weeks 3–7 | Run two further live cycles; WebriQ specialists, automation, and agents execute work; client team handles only decisions and approvals that require them; blockers and handoffs made visible and tuned |
| Measure and decide | Week 8 | Review what moved, what remained blocked, how the selected failure mode changed, and what a 90-day expansion would look like |
Deliverables
The Foundry produces four core outputs:
A defined operational baseline — A bounded workload and a clear before-state for the selected problem (capacity, execution, or accountability). The Foundry begins with a decision criterion, not a feature list.
Three live operating cycles — The named internal operator works the actual StackShift II review queue through three complete cycles. Real work, real approvals, real cadence — not a demo or sandbox.
Production work completed — Output is determined by the chosen path and workload: backlog items moved (Capacity), a stalled initiative pushed into production (Execution), or an ongoing workstream placed inside a controlled accountability loop (Accountability).
A decision document and 90-day expansion plan — A measured review of what changed, where friction remains, what the operating model should take on next, and the case for — or against — continuing into a full StackShift II engagement.
Optional Second Layer: The Canon
When the selected operational problem calls for it, a Canon layer can be included in the Foundry engagement. The Canon is a knowledge graph plus verified claims bound across it, plus a composition discipline that renders pages and answers from those claims. It is the durable asset underneath the outputs, rather than any individual page being the asset itself.
When the Canon layer is included, the engagement can deliver:
- A scoped Canon for one domain
- Three live review-queue cycles
- Ten to fifteen compositions published from that Canon
- An AI-visibility baseline with a 90-day projection
Canon terminology:
| Term | Definition |
|---|---|
| Canon | A business's complete, verified, machine-legible body of claims about its own domain — the single source of truth from which pages and answers can be composed |
| Claim | A single verifiable statement, bound to the entities it concerns, carrying its own source and confidence |
| Composition | Any page, answer, or feed rendered from the Canon for one surface; never precious, always regenerable |
Commercial Terms
| Item | Detail |
|---|---|
| Price | $9,000 — fixed, one-time; no monthly component during the Foundry engagement |
| Duration | Eight weeks from kickoff |
| Conversion credit | The full $9,000 is credited against months 1–3 of a StackShift II engagement signed within 30 days of Foundry completion |
| Capacity | Two Foundry slots per month; delivery capacity is genuinely limited because this is live operating work, not templated onboarding |
| Client requirement | A named internal operator with a scheduled weekly review block, access to the people and systems needed for the chosen workload, participation in scoping, and participation in the final decision review |
| Technical architecture | Runs on StackShift II architecture: Supabase, Next.js and Vercel, with pgvector-backed knowledge and retrieval where required and agent-governed workflows around the work |
If You Do Not Convert
Clients who complete the Foundry but do not proceed to a full StackShift II engagement retain:
- All production work completed during the engagement
- The Foundry baseline and decision document
- All operational artifacts created for the organisation
- If a Canon was built: a structured export of entities, relationships, and verified claims — including source, confidence, and lineage — in portable open formats such as JSON and JSON-LD
What remains with StackShift II is the operating machinery: live embeddings (where used), agents, the review queue, execution workflows, and the continuous operating loop that keep work moving after the Foundry.
Who the Foundry Is For
The Foundry is built for B2B teams with real digital work to put through the model. It is not a fit for teams seeking a product evaluation without committing meaningful work, or organisations expecting a templated or self-serve onboarding process.
The engagement is positioned as a bounded test of an operating relationship, not a software demo.
Technical Context
StackShift II is described by WebriQ as an operating relationship, not a software subscription. The Foundry is the commercial mechanism by which organisations test that relationship on a defined, meaningful workload before committing to a full engagement. The architecture underlying StackShift II includes Supabase, Next.js, Vercel, pgvector-backed knowledge and retrieval, and agent-governed workflows.