WebriQ / StackShift II

How the system actually works

The whole flow on one line. Your product truth and your expertise go in on the left, become the Canon in the middle, and are composed into everything on the right.

Start here

Your website now has two visitors. A human being who reads it, and an AI system that retrieves from it and decides whether to recommend you. StackShift II serves both from one permanent record of what your company knows. Everything else the system produces is generated from that record, on demand.

Who acts

• You — direct and approve
• The platform — executes
• WebriQ — operates and governs

The operating model

1. Intake — Everything your company knows goes in

Your specs, your catalogs, your sales answers, your hard-won expertise. Two to four hours with someone who genuinely knows the business. This raw material is what gives the output your voice, your specificity, and your judgment.

Canon: The intake session sets the ceiling on everything downstream. Depth here determines depth everywhere else.

• What we collect — Product data, technical specs, case histories, the answers your best salesperson gives.
• Who participates — A real subject-matter expert. The depth of this session sets the ceiling on everything downstream.
• Time required — Two to four hours, across one or two sessions.
• How often — Once at the start. The record grows continuously after that.

WebriQ leads

2. The core of the system — It becomes one permanent record of truth

AI reads all of it and turns it into structured, connected facts. Your products, your capabilities, your claims, and how they all relate. This record is the one authoritative version of what your company knows. It is the thing that appreciates over time.

Canon: This record is the canonical source of truth. Every page, feed, and answer the system produces is generated from it.

• Why it matters commercially — Legacy websites store your knowledge inside pages. When the page changes, the knowledge changes with it. Here the knowledge sits above the page and outlives it.
• Update one fact, update everywhere — Change a spec in the record and every page, feed, and AI-readable output carries the change automatically.
• You own it — The record is your asset. It stays yours, and it grows with every approved item.
• The compounding asset — A deeper record produces sharper, more specific, more citable output. Depth accumulates month over month.

Platform

3. Publishing — It publishes to both visitors at the same time

One record produces two outputs simultaneously. A page a person reads, and a parallel structured version an AI system can retrieve, parse, and cite. Both come from the same source, so both stay in sync permanently.

Canon: Pages are render targets. The record is permanent, the page is regenerable at any time.

For the human visitor:

• Product and category pages
• Comparison and buying guides
• Editorial and landing pages

For the machine visitor:

• Structured schema and feeds

• AI retrieval documents

• Semantic APIs and MCP endpoints

• Why two tracks — A human scans and skims. An AI system retrieves broadly and cuts aggressively. Each track is shaped for how its visitor actually behaves.

• Always current — Outputs refresh from the record automatically. Accuracy becomes a property of the system.

• Cadence — Publishing runs continuously, paced by how fast you approve.

• Speed and security — Pages render at the edge, pre-built for performance and global delivery.

Platform

4. The market — Buyers and AI systems find you, read you, and cite you

Your buyer asks an AI system who they should call. The system retrieves, evaluates, and names a handful of companies. That shortlist forms long before anyone fills out a form. Being retrievable and citable is what puts you on it.

• What gets measured — Citation share in your category, tracked nightly. Which questions surface you, and which ones surface a competitor.
• Rank and recommendation differ — Roughly 60% of AI citations come from outside the top 20 organic results. Position on a results page and presence in an answer are separate outcomes.
• Owned surface — Conversational AI runs on your own domain, so the exchange with your buyer happens on infrastructure you control.
• Optional extension — PipelineForge converts citation and engagement signal into qualified outbound contact.

Measured nightly

5. Your weekly involvement — The system finds the gaps and asks you what to do

Citation data shows where you are absent from the conversation. The platform drafts what would fill that gap and puts it in a queue. One named person on your team opens the queue, approves what is right, redirects what is off. Plain language, one screen, a few minutes at a time.

• Who you need — One named person with a real block of time each week. This single commitment is the difference between the system compounding and the system idling.
• Time required — A defined response window per batch, typically 48 to 72 hours, written into the agreement.
• Publishing waits for you — Every item publishes on your approval. When the queue sits, publishing holds. Your approval speed sets your publishing speed.
• Monthly, one level up — A senior contact reviews visibility trends and sets direction for the next cycle.

You decide

And then it runs again, deeper each time

Every approved item returns to the permanent record and makes it richer. A richer record produces sharper output. Sharper output earns more citations. More citation data reveals the next gap. Month twelve carries depth that month one could only gesture at, because the asset underneath has been accumulating the entire time.

Three parties, three jobs

• You — Set direction. Approve the work. Topic and market priorities, weekly queue approval, brand and content boundaries, monthly strategy review.
• The platform — Generate. Publish. Measure. Extraction into the record, dual-track publishing, nightly citation scoring, gap detection and queue items.
• WebriQ · the operator — Run the engine room. Record build and governance, AI agents and workflows, infrastructure and deployment, monthly reporting and strategy.

The Canon: four rules the architecture holds to

One record above. Everything else is generated.

• The record is canonical — The knowledge graph is the permanent, authoritative source. It holds what your company knows, structured once and kept current.
• Pages are render targets — Every page, feed, API, and AI answer is generated on demand from the record, and can be regenerated at any moment.
• Change once, propagate everywhere — Update a fact in the record and every downstream output carries the correction automatically.
• Authority stays with the domain — Your product system remains the operational truth for product data. The publishing engine reads from it and leaves it under your control.

The architecture: six layers

The architectural principle: Traditional websites are CMS-first. The page is the thing, and your knowledge lives inside it. StackShift II is semantic-object-first. A structured knowledge graph holds the truth, and every page, feed, API, and AI answer is assembled from it on demand. Six layers, each owning one responsibility.

Each layer owns a single job and hands off cleanly to the next. The database holds truth. Agents do the enrichment. The engine orchestrates. The rendering layer is stateless and disposable.

Layer	Responsibility	Governed by
Supabase	Canonical datastore — the single source of truth for all semantic knowledge objects: content, entities, facts, claims, relationships, and embeddings. Also holds agent state and the review queue.	WebriQ
PIM	Product domain system — canonical operational truth for product data. Pricing, specifications, availability. The publishing engine reads from it and leaves it untouched.	Customer
AI Agents	Intelligence layer — extraction, enrichment, generation, optimization. Agents parse raw assets, pull entities and relationships, generate media metadata and alt text, and produce render intents.	WebriQ
pgvector	Semantic retrieval — embeddings and vector search. Numeric representations of your content that make it findable by meaning, which is how AI systems actually retrieve.	WebriQ
Build engine	Composition and orchestration engine — reads semantic objects and builds every output format, deploying continuously. It orchestrates, and storage stays upstream where it belongs.	WebriQ
Next.js / Vercel	Human rendering layer — stateless edge rendering. Pages are pre-rendered or server-rendered at the edge for speed, security, and global delivery. Every page is regenerable.	WebriQ

The data path: four lanes

Lane 1 · Ingestion: Your sources (expertise: documents, your site, calls, photos; and PIM product data) → Parse to machine-readable text and structured form → AI Agents extract entities, facts, claims, relationships, and taxonomy.

Lane 2 · Storage — the canonical layer: Supabase (semantic objects, graph relationships, agent state, review queue) + pgvector (vector index for retrieval by meaning) + PIM (product truth, owned and operated by you).

Lane 3 · Assembly: Render intents (structured signals: which output, which audience, which format) → Build engine composes web content, blogs, articles, FAQs, newsletters, social posts — plus machine feeds → Both tracks live (same source, same moment, two shapes).

Lane 4 · Delivery: Human track (Next.js on Vercel — web content, blog posts, articles, FAQs, newsletters, social posts) in parallel with Machine track (JSON-LD schema, AI retrieval documents, semantic APIs, LLM feeds, MCP endpoints).

Lane 5 · Feedback — nightly: Citation monitor scores visibility across AI systems nightly → Review queue held in Supabase, surfaced in plain language → You approve → Back to the graph (approved items write new objects and the cycle deepens).

Read the boundaries. Agents write into Supabase and pgvector. Your team writes into the PIM. The build engine reads from all three and leaves all three untouched. Human approval gates the step between a generated object and a published output. Those three boundaries are what let the system run continuously while your brand and your product data stay under your control.

The seven-step pipeline

Every asset that enters the system passes through the same sequence. Step seven is the one that makes this infrastructure.

1. Ingest — Two sources enter, and nothing else does: your expertise (documents, your existing site, recorded calls, photos) and your PIM's product data. Legacy content is transformed from unstructured files into structured input.
2. Parse and normalize — Content is parsed into machine-readable text and structured form. Product data is normalized into canonical product objects. Media is handled as first-class semantic content.
3. Extract and enrich — Agents pull entities, facts, claims, relationships, and taxonomy. Media assets receive generated metadata, alt text, and contextual links. Every object is linked into one unified knowledge graph.
4. Semantic storage — Objects are written to Supabase. Vector embeddings are written to pgvector. This graph is the permanent record, and every output that follows is an expression of it.
5. Render intent generation — Agents emit render intents, which are structured signals describing what output to create, for which audience, in which format. The human and machine tracks are determined at this step.
6. Assembly and deploy — The build engine assembles and deploys every composition — web content, blog posts, articles, FAQs, newsletters, and social posts — alongside machine-readable outputs, all at once, from the same objects, gated by your approval.
7. Continuous regeneration — When an upstream object changes, every dependent output regenerates automatically. Manual republishing disappears. The entire published presence stays current by default.

Six rules that hold the architecture together

• Facts belong to domain systems — The PIM owns product truth. Supabase owns content truth. Publishing layers are consumers, and they remain consumers permanently.
• The build engine orchestrates only — The engine assembles and publishes. Canonical data stays upstream, and editorial authority stays with the domain.
• Pages are disposable outputs — Every rendered output is regenerable from upstream semantic objects at any time. The graph is permanent, the page is temporary.
• Semantic objects remain canonical — The knowledge graph is the permanent record. Pages, feeds, APIs, and embeddings are expressions of it.
• Structures first, pages second — Semantic enrichment always precedes rendering. Every generated page traces back to structured data.
• WebriQ governs orchestration — You manage operational truth for products and content. WebriQ controls publishing infrastructure, governance, and delivery.

The seven questions people ask about that picture

What exactly is the Canon? — Your complete, verified, machine-legible body of claims about your own field. A claim is a single verifiable statement — bound to the thing it concerns, carrying its own source, its confidence, and how long it stays true. The Canon is the body of them. It is the only precious thing in the picture, because everything else is composed from it.

Why call the pages "compositions" rather than content? — Because a page is not content. It is a projection of your content onto one surface, for one reader, in one language, at one moment. Once you see it that way, the page stops being the thing you keep. Delete every page you have; if the Canon survives, you have lost nothing — the compositions regenerate. That is also why replatforming stops being a migration project.

Why are there two ways in, and not one? — Because product truth and expertise behave differently. Specifications, dimensions, materials, certifications and availability stay in the system you already run, and are copied in one way only — nothing downstream can write back to them. Everything else is read and separated into individual claims, each carrying the source it came from. They meet in the Canon but never blur.

Who decides what becomes true? — You do, at the review queue. Everything the system proposes arrives there in plain language, showing what is proposed, why, and the exact source. Approval is a ladder rather than a switch, set separately for each kind of work: it starts as suggestion only, moves to drafting and holding, and only earns the right to publish-then-be-audited after clearing roughly 98% approval across its last two hundred items. Mechanical propagation is the only thing that ever runs unattended.

What can never be automated, no matter how well it performs? — Any brand-new public claim about your business. That stays at drafted-and-held permanently, regardless of track record — automation earns speed, never the right to assert something new on your behalf. And contradictions never resolve themselves: if a new document disagrees with a claim you already approved, both versions arrive in the queue with their sources rather than one quietly overwriting the other.

What happens when a single claim changes? — This is the moment the model earns itself. In the page-as-asset world, someone has to remember every page, feed and document where a price or a specification appears, and the structured markup drifts out of sync the moment they miss one. Here the claim is a single record with known bindings. It changes once, and every composition bound to it knows: the exact sentence expressing it is patched, the structured data regenerates, every other language flags just that line for review, and everything that never touched the claim is left alone.

Why does this decide who gets cited? — An AI system does not read your page the way a person does. It extracts what your page claims and cites the source it can most confidently attribute those claims to. If your claims exist only as prose fused into hand-authored pages, they are hard to extract, impossible to verify, and easy for a competitor with cleaner structure to outrank — even where your expertise is deeper. The machine track exists precisely to remove that ambiguity.

How something becomes true in your Canon

Nothing enters unapproved. The only question is how much has been earned. Everything the system proposes arrives in one queue, written in plain language, showing what is proposed, why, and the exact source it came from. Approval is not a single switch — it is a ladder, set separately for each kind of work, and every rung has to be earned by a track record before the next one unlocks.

• Rung one — It only suggests — The system proposes; a person decides, every single time. Nothing is written anywhere until someone says yes.
• Rung two — It drafts, then waits — Work is written and held. It reaches the queue, never a visitor. You approve, amend, or reject with a reason.
• Rung three — It publishes, you still audit — Unlocked for one kind of task only after it has cleared roughly 98% approval across its last 200 items. Then: 72 hours to review, one-click undo.
• Rung four — It runs on its own — Reserved for propagation with no judgement in it — a corrected specification copying itself into the sentences that state it. No new wording.

Three things that do not bend:

• A ceiling that never lifts. Any brand-new public claim about your business stays at rung two forever, no matter how good the track record. Automation earns speed, never the right to assert something new.
• Contradictions surface, they never resolve themselves. If a new document disagrees with a claim you already approved, both versions arrive in the queue with their sources. Neither is silently overwritten.
• Levels fall as easily as they rise. Spot-checks continue after a rung is earned. If they start failing, that kind of work drops back down a rung automatically, without anyone having to notice.

What this asks of you, and what it promises back:

• About an hour a week. One queue, plain language, no jargon and no interface to learn.
• Claims within a day, suggestions within two. If you do not get to it, it waits — it does not publish.
• A rejection is not a dead end. Your reason is recorded and sent back to the step that produced it.
• Your speed sets the pace. The queue is the throttle on the whole operation, and it is yours alone.

The Canon: stated technically

Canonical knowledge objects are the source of truth.

• Semantic-object-first — The future architecture replaces the CMS-first model. A structured knowledge graph sits above every output and outlives all of them.
• Render targets are generated on demand — Pages, APIs, feeds, and AI outputs are assembled from durable semantic structures whenever they are requested.
• Change propagates by architecture — Update an object once and every dependent output regenerates, because outputs hold a live reference back to the object.
• Dual-track by default — Machine-readable output is produced as a property of the system, at the same moment as the human-facing page, from the same source.