StackShift II Technical Overview

StackShift II: AI-Native Publishing Infrastructure — Technical Overview for Engineering Leadership

Document Type: Technical Architecture Reference Audience: CTOs, VP Engineering, Principal Architects, Infrastructure Teams Optimization: LLM-ready knowledge base format Status: Production-ready enterprise system (June 2026) Source: WebriQ Engineering Documentation

Executive Overview StackShift II is a semantic-object-first publishing infrastructure that inverts the traditional CMS data model. Rather than treating web pages as the unit of truth, the system treats canonical semantic knowledge objects (stored in Supabase PostgreSQL) as the durable source of record. All outputs — web pages, APIs, embeddings, machine-readable feeds, and LLM-accessible formats — are generated on-demand from these canonical objects as ephemeral, regenerable render targets. The defining architectural principle: No layer owns another layer's data. The database owns content truth; your PIM owns product truth; your ERP owns transactional truth. These boundaries are enforced at the code level, not merely as policy.

Core Architecture: Six-Layer Reference Model StackShift II organizes all publishing operations across six strictly bounded layers, each with a single responsibility and no authority over any other layer's data. Layer 1: Canonical Datastore (Supabase + pgvector) Database Technology: PostgreSQL 15+ with pgvector extension Data Model: Semantic relational schema optimized for object-graph queries Access Pattern: Read-write via GraphQL, read-only from publishing layer Security Model: Row-level security (RLS) enforced at database layer What Lives Here: Semantic Content Objects — Articles, guides, case studies, narratives, FAQs, structured documentation Entity Records — Products, companies, people, concepts, locations, technical specifications Factual Relationships — Semantic edges: "product X solves problem Y," "solution A complements solution B," "content piece C references entity D" Vector Embeddings — pgvector-native embeddings for semantic search, generated by AI enrichment layer Metadata & Governance — Creation/modification timestamps, authorship, approval state, publishing status (draft, approved, active, archived) Taxonomy Assignments — Industry classification, solution category mapping, SKU grouping, capability tags Critical Constraint: The database is read-write only for ingestion, enrichment, and editorial pipelines. The publishing layer (Layer 3) reads from this layer but never writes back to it. All data mutations flow through designated ingestion pipelines with validation gates. Performance Characteristics: Row-level security evaluated at query time; indexes maintained on all relational edges pgvector similarity search (<->operator) scales to millions of embeddings with reasonable latency (<100ms at 95th percentile) Transactional ACID properties maintained for all semantic object mutations Real-time subscribers via PostgreSQL LISTEN/NOTIFY for downstream trigger events Backup and point-in-time recovery enabled; SOC 2 Type II audit logging on all writes

Layer 2: Domain Authority Systems (PIM, ERP, Master Data) Architecture Pattern: Read-only consumption of specialized domain systems Integration Method: Webhook-triggered and scheduled polling ingestion pipelines Data Flow Direction: Domain system → StackShift II (unidirectional) Product Information Management (PIM) — Authoritative Product Domain Your PIM is the canonical source for all product-centric truth: Base pricing, tier-based pricing, volume-based pricing, customer-specific overrides Product specifications, configurations, variants, SKU hierarchies Availability and inventory status (real-time sync optional) Product-to-product relationships (bundles, complements, alternatives, predecessors) Category taxonomy, product family grouping, segment assignment Compliance metadata (certifications, regulatory attributes) How it integrates: PublishForge consumes product semantic objects from PIM via read-only sync pipeline When a PIM record changes (price update, new SKU, availability change), a webhook fires Sync pipeline validates the change and updates the corresponding semantic object in the canonical datastore Change detection triggers downstream regeneration of all dependent outputs (product pages, comparison pages, category pages, JSON-LD Product schema, vector embeddings) If sync fails on any record, that object moves to needs_review state; it does not participate in publishing until the error is resolved Conflict resolution: PIM data always wins in case of divergence; publishing layer cannot override product truth Enterprise Resource Planning (ERP) Extension Pattern The same domain-authority pattern generalizes to ERP and master-data systems: Transactional Data Authority: ERP is the canonical system for inventory balances, order status, fulfillment state, pricing overrides, customer-specific terms Product Master Data: If your ERP is the system of record for product master data (specs, hierarchies, relationships), it becomes a first-class data source Ingestion Pipeline: Dedicated ERP sync pipeline with its own validation rules, conflict detection, and error handling Data Model Mapping: ERP attributes are normalized into product_objects.normalized_data field in the canonical graph Downstream Impact: ERP changes trigger the same publishing regeneration loop — all human pages, machine outputs, embeddings, and APIs reflect the change within seconds Example ERP Integration Workflow: Price change in ERP system Webhook triggers price-sync pipeline Pipeline validates change and updates semantic object in database Change detection event fires to PublishForge PublishForge regenerates all dependent outputs: Product pages (human track) JSON-LD Product schema with updated offers (machine track) Vector embeddings (semantic layer) GraphQL product APIs LLM-readable pricing feeds MCP endpoints All outputs live within 30–60 seconds; no manual republishing required Master Data Management (MDM): For organizations maintaining a dedicated MDM system (Informatica, Talend, SAP MDM), the pattern is identical. MDM becomes an authoritative domain plane feeding the semantic graph, with the same validation, conflict detection, and governance rules.

Layer 3: PublishForge (AI Orchestration Engine) Architecture Type: Event-driven orchestration engine; never a source of record Execution Model: Continuous streaming with event-based triggers and scheduled batches Scale: Handles 10,000+ SKUs, 1,000+ content pieces, 50+ domains without infrastructure changes Core Responsibilities: 3.1 Consume Semantic Objects and Generate Render Intents PublishForge reads canonical semantic objects from the database and, through AI reasoning, generates explicit render intents — structured instructions specifying what outputs should be generated:

Render Intent Structure (JSON):
{
"object_id": "product_12345",
"object_type": "product",
"render_targets": [
{
"format": "web_page",
"audience": "human",
"layout_template": "product_detail_v2",
"design_tokens": ["light_mode", "cta_prominent"],
"priority": "high"
},
{
"format": "json_ld_schema",
"schema_type": "Product",
"audience": "machine",
"priority": "critical"
},
{
"format": "vector_embedding",
"model": "text-embedding-3-large",
"index": "product_semantic_index",
"priority": "high"
},
{
"format": "mcp_endpoint",
"endpoint_type": "product_detail",
"audience": "ai_agent",
"priority": "high"
}
],
"dependencies": ["category_page", "comparison_page"],
"freshness_requirement_minutes": 5
}

Why render intents matter: They decouple what knowledge exists (the semantic object) from how it's expressed (the outputs). Agents can reason about output strategy independently of assembly, allowing fine-grained control over which outputs are generated, their priority, and their freshness requirements. 3.2 Assemble Dual-Track Outputs Simultaneously Every publish operation generates two output streams from the same semantic objects: Human Track (Synchronously Generated): HTML pages rendered via Next.js (pre-rendering or server-rendering) Responsive design applied via component library Layout templates determine page structure Design tokens (colors, typography, spacing) applied via CSS custom properties Images, media, and assets embedded Navigation and internal linking resolved Accessibility compliance (WCAG AA) validated Machine Track (Simultaneously Generated): JSON-LD structured data (Product, FAQPage, Article, Organization, etc.) LLM-readable text formats (markdown, plain text with semantic markers) Vector embeddings (semantic search layer) GraphQL API endpoints (programmatic object access) Atom/RSS feeds (LLM subscription-compatible) MCP (Model Context Protocol) endpoints for AI agent access Sitemap and robots.txt (crawler directives) Critical Design Constraint: Both tracks are generated from the identical source objects in the same orchestration cycle. This ensures consistency and prevents the human and machine versions from diverging. 3.3 Event-Driven Continuous Regeneration The regeneration loop is event-driven, not scheduled: When a semantic object is created, modified, or enriched, a database trigger fires a semantic_object_mutated event This event is published to a message queue (Redis Streams or AWS SQS) PublishForge subscribers consume the event and enqueue regeneration for all dependent outputs Dependent relationships are calculated at runtime based on the object graph (e.g., if a product changes, all category pages, comparison pages, and recommendation feeds that reference it are marked for regeneration) Regeneration happens asynchronously but completes within seconds (typically 5–30 seconds depending on complexity) Outputs are staged to a CDN-backed staging environment, validated, then atomically promoted to production Why Event-Driven Over Scheduled Crons: Scheduled crons introduce staleness windows (e.g., if cron runs hourly, data can be up to 60 minutes stale) Event-driven ensures every output is within seconds of its upstream object Critical outputs (pricing, availability) stay fresh automatically No configuration needed — the system reacts to changes, not to a fixed schedule Failed regenerations are captured and retried with exponential backoff Example Event Flow: ERP sync pipeline updates product_12345.price in database Database trigger fires semantic_object_mutated event Event includes: object ID, object type, changed fields, timestamp PublishForge consumer receives event; queries object graph to find dependents Dependents identified: product page, 3 category pages, 2 comparison pages, embedding PublishForge enqueues 7 regeneration jobs Jobs execute in parallel (concurrent workers) Each job: render page/output, validate, stage to CDN After all jobs complete, outputs promoted to production (atomic) Within 5–10 seconds, all dependent outputs reflect the price change 3.4 Orchestration Guarantees No Overwrites: PublishForge reads from domain systems but never writes back to them Idempotent Operations: Regenerating the same object twice produces identical outputs Atomic Promotion: All outputs for an object either go live together or not at all Failure Isolation: If one output fails to generate, others are not blocked; failures are logged and retried Rollback Capability: Previous versions of outputs are retained; can rollback to prior version if needed Audit Trail: All regenerations logged with source event, start/end time, worker ID, and outcome

Layer 4: Next.js / Vercel (Human Rendering Layer) Framework: Next.js 15+ (App Router) Deployment: Vercel Edge Network (globally distributed) Rendering Strategy: Hybrid (Static Site Generation + Server-Side Rendering) Performance Targets: < 100ms FCP, < 2s LCP, core Web Vitals green Architectural Properties: Stateless Rendering: All rendering logic is pure functions of input data (semantic objects). No state persists in the rendering layer. Regenerability: Any page can be regenerated instantly if upstream data changes. Pages are not canonical — the knowledge graph is. Global Distribution: Next.js pages are pre-rendered to static HTML and served from Vercel's global CDN, eliminating origin server latency Fallback Rendering: If a page must be generated on-demand (e.g., personalized content), Next.js ISR (Incremental Static Regeneration) or dynamic server rendering handles it Security Headers: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options automatically applied by Vercel Accessibility: WCAG AA compliance validated in every render; missing alt text or semantic HTML flagged as build errors Responsive Design: Mobile-first CSS with responsive breakpoints; tested across viewport sizes Data Flow in Rendering: Semantic object arrives at PublishForge PublishForge reads object data and render intent Next.js data-fetching functions (getStaticProps, getServerSideProps) retrieve object from database Component tree renders object into HTML/JSX Design tokens applied via CSS-in-JS or utility classes Images optimized via Next.js Image component (WebP, dynamic sizing) Page serialized to static HTML and written to CDN Static page served globally; no origin latency Configuration & Deployment: Each domain/site gets its own Next.js project Environmental configuration (API endpoints, CDN origins, feature flags) injected at build time Deployment is fully managed; PublishForge triggers builds, Vercel handles infrastructure Preview deployments for staging validation before production promotion Automatic rollback if deployment health checks fail

Layer 5: pgvector (Semantic Retrieval Layer) Database Extension: pgvector (open-source PostgreSQL extension) Embedding Model: Multi-model support (OpenAI, Anthropic, Cohere, open-source embeddings) Vector Index Type: IVFFlat or HNSW (configurable based on scale) Latency Target: < 100ms for similarity search at 95th percentile Capabilities: 5.1 Semantic Search Incoming query is embedded using the same model as indexed content k-nearest neighbor search finds semantically similar objects Results ranked by cosine similarity and contextual relevance Used for: Site search (internal documentation, product discovery) Related articles/products (recommendations) Content-to-content linking (internal hyperlinks) 5.2 LLM Context Injection When an external LLM (ChatGPT, Claude, Gemini) needs context about your business, it queries the pgvector index Query is "What products solve problem X?" — gets embedded Search returns top-k similar products, specifications, and case studies LLM uses these as context for answer generation and citation This is the mechanism enabling your content to be cited in AI-generated responses 5.3 Recommendation Engine Product embeddings are clustered; similar products grouped When a user views product A, system finds top-N nearest neighbors "Customers also viewed" or "Frequently bought with" populated from embedding proximity Powers both human recommendations (site UI) and machine recommendations (API feeds) 5.4 RAG (Retrieval-Augmented Generation) for Internal AI Agents Internal chatbots, knowledge assistants, and automation agents use pgvector for context retrieval Agent query is embedded; most relevant documents retrieved Documents injected into agent's context window Agent can cite or summarize retrieved documents with confidence 5.5 Compliance & Audit Vector embeddings do not contain personally identifiable information (PII) Embeddings are deterministic (same input always produces same embedding) Embedding generation is logged; can audit which model version produced which embedding Embeddings can be regenerated if model changes without losing data GDPR/CCPA: Embeddings for user-related content can be deleted on request Performance & Scale: IVFFlat index: Fast index build, good for < 1M vectors, slower search HNSW index: Slow index build, better for > 1M vectors, faster search, higher memory Typical setup: IVFFlat for < 100K vectors, HNSW for 100K–10M vectors Queries scale to millions of vectors with < 100ms latency Index size: ~1–2KB per vector (overhead depends on index type) Example Use Case: AI Integration User asks external AI: "What's your recommendation for a lightweight manufacturing solution?" AI system has access to your semantic graph via pgvector AI embeds the query pgvector returns top 10 products + related case studies AI synthesizes answer using retrieved context AI response cites your products with links back to product pages

Layer 6: AI Agents (Intelligence Layer) Architecture: Agentic orchestration with human-in-the-loop governance Models: Multi-model support (Claude, GPT-4, specialized fine-tuned models for domain extraction) Execution Model: Event-triggered agents with optional scheduled batch runs Governance: Every agent output requires human review/approval before publishing Agent Capabilities: 6.1 Semantic Extraction Raw input (PDF, document, webpage) sent to extraction agent Agent parses structure and extracts semantic objects: Key entities (products, companies, people) Facts and claims (specifications, capabilities, relationships) Taxonomies (industry, use case, compliance) Extraction is validated: all required fields present, formats correct, claims verified Output: Structured JSON-formatted semantic objects ready for database ingestion Example: Upload technical whitepaper → Extract product specs, capabilities, comparison claims 6.2 Enrichment & Linking After extraction, enrichment agent adds context: Links to related products or companies (cross-references) Taxonomic assignments (categorization) Derived relationships ("Product A solves Use Case B") Contextual metadata (target audience, reading level, technical depth) Enrichment applies business rules (pricing tiers, customer segments, feature groupings) Output: Fully contextualized semantic objects 6.3 Generation & Variation Generation agents create multiple output variations from canonical objects: Alternative text summaries (executive summary, technical deep-dive, elevator pitch) Comparison tables and matrices FAQ generation from product specs or documentation SEO-optimized meta descriptions and title variations Schema markup variations (Product, BreadcrumbList, FAQPage) Variations are stored as alternative expressions of the same object Human selects preferred variation or blends multiple for final output 6.4 Optimization (Continuous Improvement) Optimization agents monitor performance metrics: Page engagement (scroll depth, time on page, CTR) Search ranking and impression share (external SEO data) Conversion rate (if ecommerce) AI visibility (mentions in AI-generated answers) Agents analyze underperforming content and suggest optimizations: Headline variations that might improve CTR Missing information that competitors include Structural changes (reordering, emphasis) that improve engagement Changes are staged and human-reviewed before publishing 6.5 Governance Boundaries All agent actions operate within defined governance gates:

Pipeline: AI Generates → Human Reviews → Human Approves → PublishForge Publishes
↑ ↑
(Cannot Bypass) (Cannot Bypass)

Quality Gates (Pre-Review): Extracted entities must pass completeness checks (required fields populated) Relationships must have defined types (not vague associations) Taxonomic assignments must be from approved vocabularies Fact claims must have confidence scores; low-confidence claims flagged Generated text must meet readability standards (Flesch-Kincaid, passive voice count) Schema markup must validate against JSON-LD schemas Human Review Gate: All agent outputs reviewed by designated human reviewers before entering publishing pipeline Review can be lightweight (confirm extraction is correct) or heavyweight (full editorial review) Reviewers have dashboard showing all pending approvals, with diffs highlighting agent changes Objects with rejections move to needs_revision; agents are notified and can retry with modifications Approval Gate: After human review, designated approvers (content manager, product manager, subject matter expert) approve for publishing Approval is time-stamped and audited Approved objects transition to active state and participate in output generation

Transactional & Back-Office System Integration StackShift II provides clean integration surfaces for transactional and back-office systems through the domain-ownership principle. Integration Architecture Principle Domain ownership is enforced at the code level: Each system owns its domain and is responsible for maintaining truth within that domain. StackShift II consumes domain data read-only and expresses it across human and machine outputs.

┌─────────────────────────────────────────────────────────┐
│ StackShift II Publishing │
│ (Stateless Orchestration & Rendering) │
└────────────┬──────────────┬──────────────┬──────────────┘
│ │ │
Reads-only Reads-only Reads-only
│ │ │
┌────────▼──┐ ┌──────▼────┐ ┌────▼─────────┐
│ PIM │ │ ERP │ │ Master Data │
│(Products) │ │(Inventory)│ │ (Entities) │
└───────────┘ └───────────┘ └──────────────┘
│ │ │
Write-only Write-only Write-only
│ │ │
Your Systems Your Systems Your Systems

Product Information Management Integration Data Ownership: PIM is the authoritative system for all product-centric information Sync Architecture: Polling Pattern: PublishForge polls PIM API on scheduled intervals (configurable: 5-min, 15-min, hourly) Webhook Pattern: PIM sends change notifications to PublishForge; PublishForge validates and applies changes immediately Hybrid: Polling + webhook (webhook for real-time changes, polling as fallback/reconciliation) Data Mapping & Transformation:

PIM Data → Validation Pipeline → Normalization → Semantic Objects → Publishing

PIM.product.id → product_object.external_id
PIM.product.name → product_object.title
PIM.product.specs → product_object.specifications (structured)
PIM.product.pricing → product_object.price_variants (multiple tiers)
PIM.product.images → media_object (embedded, optimized)
PIM.product.relationships → relationship_edges (graph)

Conflict Resolution & Error Handling: If PIM data conflicts with published data: PIM always wins If sync fails (timeout, validation error): Object enters needs_review state Retry logic: Exponential backoff (30s, 2m, 10m, 1h) for transient failures Alerting: Team notified if sync failure persists > 1 hour Manual override: Human can force resync or correct data in database if needed Real-Time Availability & Inventory: If inventory is critical (ecommerce SKUs), webhook-based sync ensures < 1-minute freshness Availability state changes trigger page regeneration within 30 seconds Product pages show "in stock," "low stock," or "out of stock" with current data Machine outputs (JSON-LD, feeds) reflect current inventory status Enterprise Resource Planning Integration Data Ownership: ERP is the authoritative system for transactional, operational, and (optionally) product-master data Typical ERP Data Integrated: Inventory levels and warehouse locations Pricing (base, tiered, customer-specific overrides) Fulfillment/shipping information Customer order history and repeat-purchase data Supplier and vendor information Compliance certifications and regulatory status Sync Pattern (Similar to PIM): Designated fields in ERP configured as "publishable" Change detection pipeline monitors designated fields On change, webhook triggers or polling detects new data Validation pipeline ensures ERP data conforms to expected schema Normalization pipeline maps ERP attributes to semantic objects Semantic objects updated in canonical datastore Change event fires; dependent outputs regenerated Within 30–60 seconds, all outputs reflect ERP state Example Workflow: Real-Time Price Update

Timeline:
T+0s: Price changed in ERP
T+2s: Webhook received by sync pipeline; validation begins
T+3s: Normalized, inserted into canonical datastore
T+4s: Change event published
T+5s: PublishForge begins regenerating:
- Product detail page (HTML)
- JSON-LD Product schema
- Vector embeddings
- GraphQL API
- LLM-readable feeds
T+8-15s: All regeneration jobs complete; outputs staged
T+16s: Atomic promotion to production
T+17s: End users / AI systems see updated price globally

Scale & Performance: Handles 10,000+ ERP record changes per hour without bottleneck Concurrent sync and publishing (other objects publish while one is syncing) Failed syncs don't block healthy syncs Reconciliation: Full ERP scan runs nightly to catch any missed changes Prospecting & Sales Intelligence Integration: PipelineForge Architecture: Bi-directional data flow between StackShift II knowledge graph and PipelineForge prospecting engine Data Flow Diagram:

┌─────────────────────────────────────────────────────┐
│ StackShift II Knowledge Graph │
│ (Your Business Knowledge, Content, Products) │
└──────────────────┬──────────────────────────────────┘
│
│ Reads: Business narrative, value props,
│ case studies, specifications, capabilities
│
▼
┌─────────────────────────────────────────────────────┐
│ PipelineForge Prospecting Engine │
│ - Injects WebriQ's knowledge into outreach │
│ - Identifies ICP-matched companies │
│ - Generates personalized prospecting sequences │
│ - Handles inbound replies and lead qualification │
└──────────────────┬──────────────────────────────────┘
│
│ Writes: Prospect records, conversation
│ metadata, engagement signals
│
▼
┌─────────────────────────────────────────────────────┐
│ StackShift II Canonical Datastore │
│ (Prospect Context, Engagement Data) │
└─────────────────────────────────────────────────────┘

How It Works: 6.1 Knowledge Injection PipelineForge reads your semantic knowledge graph to craft personalized outreach Objects read: Company narrative (who you are, what you do, why you're different) Value propositions (key benefits, use cases, success stories) Product specifications and capabilities Case studies and proof points Testimonials and trust signals Competitive positioning PipelineForge uses this context to generate personalized messages that reflect your authentic voice and expertise 6.2 Prospect Identification & Targeting Your ideal customer profile (ICP) is defined with criteria: Industry, company size, location, revenue, employee count Technologies in use, hiring signals, growth indicators Fit to your target use cases or problems you solve PipelineForge searches 150M+ company database weekly Newly matching companies are identified and added to outreach queue Your knowledge graph informs targeting criteria and messaging angle 6.3 Personalized Outreach at Scale For each identified prospect, PipelineForge generates personalized email sequences Each sequence is informed by your knowledge graph context Personalization dimensions: Company size and industry context Relevant use cases from your case studies Specific products/services that fit their profile Value props tailored to their industry challenges Messages are sent from your email domain with authentication (SPF, DKIM, DMARC) Inbox delivery rate > 95%; not flagged as spam because messages are personalized, not templated 6.4 Inbound Reply Handling Every reply to prospecting outreach is read by AI AI categorizes: interested, has question, not interested, out of office, wrong person, etc. Routine replies handled automatically (OOO acknowledgment, wrong person redirect) High-intent replies (genuine interest, specific questions) escalated to human sales team Context provided: prospect background, messages they received, their response, recommended next action Sales team operates on qualified conversations, not cold contacts 6.5 Closed-Loop Feedback Prospect engagement data (reply received, meeting booked, pipeline stage) flows back to semantic graph This feeds continuous optimization: Which messaging angles get highest engagement? Which industries respond best? Which products resonate with which buyer profiles? Optimization agents analyze patterns and suggest refinements Outreach improves continuously without manual intervention Integration Points with StackShift II: Integration Point Data Flow Purpose Knowledge Graph SS2 → PF PipelineForge reads narrative, value props, case studies Prospect Context PF → SS2 Prospect records and engagement signals stored in semantic graph Targeting Rules SS2 → PF ICP definition influenced by your documented success patterns Message Personalization SS2 → PF Product specs, case studies injected into message generation Lead Enrichment PF → SS2 Prospect intent signals added to prospect entity records Engagement Signals PF → SS2 Email opens, clicks, replies tracked as prospect attributes Feedback Loop PF ↔ SS2 Performance metrics inform optimization agents Why This Matters: Unified Data Model: Prospect context lives in the same graph as product context Continuous Improvement: Optimization agents analyze what messaging works and refine automatically Authenticity: PipelineForge speaks in your voice because it's informed by your actual knowledge Closure: From visibility (StackShift I) → outreach (PipelineForge) → conversation → pipeline, all powered by the same knowledge base No Silos: Marketing intelligence, product data, and prospecting context are integrated, not separate systems

Operating Model: Continuous Publishing vs. Campaign Publishing Traditional Campaign Model Content updates happen in batches (quarterly releases, campaign launches) Publishing requires developer/technical involvement Updates take weeks or months from concept to live Manual republishing of dependent content Stale content between campaign cycles StackShift II Continuous Model Semantic objects are canonical; outputs regenerate automatically when objects change Content team updates objects in database or via editorial interface; infrastructure handles rest Updates propagate to all outputs (pages, APIs, embeddings) within 30–60 seconds No developer tickets; no republishing needed Entire digital presence always fresh and current Operating Timeline: Weeks 1–3: Discovery, knowledge inventory, source mapping, governance rules Weeks 4–8: Knowledge graph construction, semantic object ingestion, relationship mapping, embedding generation Weeks 9–11: Output configuration (templates, formats), testing, performance validation Week 12: Go-live and continuous operation (infrastructure runs 24/7) Operational Responsibilities After Launch: Content Team: Update objects, add new content, manage taxonomy, approve AI-generated variations WebriQ Infrastructure Team: Monitor publishing pipeline, manage integrations, optimize performance, handle alerts Your IT/Security Team: Maintain PIM, ERP, and other domain systems; ensure webhook security and data validation

Data Flow: From Raw Input to Published Output Seven-step pipeline, applied consistently to every piece of knowledge: Ingest — Raw sources (documents, product data, media) arrive via APIs, webhooks, or uploads Parse & Normalize — Unstructured content converted to structured form; relationships identified Extract & Enrich — AI agents extract entities, facts, relationships; enrichment adds context Store as Semantic Objects — Canonical objects persisted to Supabase; embeddings generated Generate Render Intents — AI determines what outputs to create, formats, audiences Assemble Dual Tracks — Human (pages) and machine (APIs, feeds, embeddings) outputs generated in parallel Publish & Serve — Outputs deployed to CDN, APIs, feeds; served globally to humans and AI systems Every object follows this pipeline. No shortcuts, no exceptions.

Performance Characteristics & Guarantees Latency Database query latency: < 50ms (p95) Semantic search (pgvector): < 100ms (p95) Page render (Next.js): < 200ms server time + network latency End-to-end input → published: 30–60 seconds for typical updates Throughput Concurrent semantic object mutations: 1,000+ per minute Output regenerations: 100+ concurrent jobs API requests: Handles 10,000+ req/sec globally Availability SLA: 99.9% uptime Failover: Automatic regional failover for infrastructure components Data backup: Hourly snapshots with point-in-time recovery Scalability Handles 10,000+ SKUs without infrastructure changes 1,000+ content pieces 50+ domains Millions of embeddings in pgvector Governance & Compliance SOC 2 Type II audit GDPR & CCPA compliance (data deletion, privacy controls) Row-level security in database All writes audit-logged with source, actor, timestamp Data encryption in transit (TLS) and at rest

Technology Stack: Detailed Component Overview Layer Technology Purpose Notes Canonical Datastore Supabase (PostgreSQL 15+) Semantic object storage pgvector extension for embeddings API Layer GraphQL Query semantic objects Real-time subscriptions via LISTEN/NOTIFY Orchestration PublishForge (WebriQ) Publish coordination Custom-built, event-driven Human Rendering Next.js 15+ (React) Web page rendering Deployed on Vercel globally Styling Tailwind CSS / CSS Modules Design tokens & responsive Performance-optimized Static Assets Vercel CDN Global content delivery Automatic optimization (images, etc.) Embeddings pgvector Vector search layer Model-agnostic; supports OpenAI, Claude, Cohere AI Models Claude, GPT-4, Fine-tuned Extraction, enrichment, generation Multi-model support Message Queue Redis Streams / AWS SQS Event distribution Triggers regeneration workflow Infrastructure AWS or GCP Underlying compute/storage Region-specific for compliance Monitoring DataDog / New Relic Performance & health Real-time dashboards Logging CloudWatch / ELK Audit trail All changes logged and queryable

Architecture Decision Records (ADRs) ADR-1: Semantic Objects as Canonical Source Decision: Semantic objects in the database are canonical; pages and APIs are ephemeral. Rationale: Single source of truth simplifies consistency Regenerable outputs mean no data duplication Enables dual-audience (human + machine) publishing without separate workflows Aligns with AI-first publishing where machines consume structured data Consequences: All updates must flow through semantic layer; no direct page edits Requires careful schema design; errors propagate to all outputs More complex initially; pays off as scale increases

ADR-2: Domain System Boundaries (No Publishing Layer Authority) Decision: PublishForge reads from domain systems but never writes back to them. Domain ownership is enforced at code level. Rationale: Prevents data corruption in authoritative systems (PIM, ERP) Clear separation of concerns Domain systems remain sources of record; publishing layer is consumer Simplifies integration and reduces complexity Consequences: All PIM/ERP updates flow through designated sync pipelines Stricter change control; requires validation gates Cannot do direct data fixes in publishing layer; must fix in source

ADR-3: Event-Driven Over Scheduled Regeneration Decision: Output regeneration is event-triggered, not scheduled via cron. Rationale: Eliminates staleness windows (data is always < 60s old) Critical updates (pricing, availability) propagate immediately More efficient (only regenerate when something changes) Scales better (no heavy scheduled jobs during peak hours) Consequences: Requires event infrastructure (Redis, SQS, etc.) More complex troubleshooting (asynchronous failures harder to debug) Retry logic necessary; needs alerting for failed regenerations

ADR-4: Dual-Track Output Generation Decision: Human and machine outputs generated simultaneously from identical objects. Rationale: Ensures consistency (no drift between human and machine versions) Both audiences served by same content update Eliminates separate "machine output" workflow Powers AI discoverability as default, not afterthought Consequences: Requires rendering templates for both human and machine formats Output validation must cover both tracks More initial template work; pays off in maintenance

Reference Implementation Pattern Typical Deployment Configuration

Environment: Production
Region: US-East (Primary), US-West (DR)
Database: Supabase (PostgreSQL 15, pgvector)
Rendering: Vercel Global CDN
Messaging: Redis Streams (or AWS SQS)
Monitoring: DataDog

Integration Points:
- PIM: REST API + webhooks, polling every 5 minutes
- ERP: REST API + webhooks, polling every 15 minutes
- PipelineForge: GraphQL subscription + REST APIs
- External AI: pgvector semantic search API

Performance Targets:
- Database latency: < 50ms p95
- Page load: < 2s LCP globally
- Regeneration: 30-60s end-to-end
- API: 10,000+ req/sec
- Uptime: 99.9%

---

Conclusion StackShift II inverts the traditional CMS model by treating semantic knowledge objects as canonical and all outputs (pages, APIs, feeds, embeddings) as regenerable render targets. This architectural shift enables: Dual-audience publishing — Human and machine outputs generated simultaneously Continuous freshness — Event-driven regeneration keeps all outputs current Domain authority preservation — PIM, ERP, and other systems remain sources of truth Operational efficiency — No developer tickets for content updates; infrastructure handles regeneration AI discoverability — Machine-readable outputs (JSON-LD, embeddings, LLM feeds, MCP endpoints) enable AI systems to find and cite your content Scale without complexity — Handles 10,000+ SKUs and 1,000+ content pieces with consistent architecture For CTOs evaluating this infrastructure, the key insight is that publishing is no longer a batch operation managed by humans — it's a continuous, event-driven process managed by agents within governance boundaries. Your systems of record (PIM, ERP, master data) remain authoritative; StackShift II orchestrates their expression across human and machine channels.

Additional Resources Product Page: webriq.com/stackshift-platform API Documentation: docs.webriq.com/stackshift-ii Deployment Guide: deployment.webriq.com (internal) Monitoring Dashboards: dashboards.webriq.com

Document Version: 1.0 Last Updated: June 2026 Audience: Technical leadership, architects, engineering teams Format Optimization: LLM-ready knowledge base Maintenance: Updated quarterly with new architectural decisions and deployment patterns