Nexus Axiom: An AI-Orchestrated Venture Builder — From Hypothesis to Hyper-Scale

Nexus Axiom: An AI-Orchestrated Venture Builder — From Hypothesis to Hyper-Scale

Adverant Research Team — Adverant Limited, Dublin, Ireland — don@adverant.ai
Version 1.0 · Date 2026-07-07 · Status Link-only preprint (noindex, nofollow)
Confidential. Grounded, zero-fabrication architecture & methodology paper; every citation verified via dual-engine grounded search and a blocking validation gate.

---

Abstract

Turning an idea into a live product is still a relay of loosely coupled human handoffs: a founder researches, a team builds, an operator scales, and context leaks at every seam. Large language model agents can now draft the research, write the code, and shape the infrastructure that each of those handoffs once required. Yet production systems that chain such agents end-to-end tend toward one of two failure modes — they strip the human out, forfeiting trust and control, or they bolt approval on as after-the-fact friction. What is missing is a principled architecture that carries a raw hypothesis all the way to a sovereign, horizontally scaling product while keeping a human in authority at every consequential step, and while keeping each customer's asset genuinely its own. We present Nexus Axiom, an AI-orchestrated venture builder structured as four human-gated stages — Catalyst (ideate), Thesis (research), Crucible (deploy), Apex (live) — each wrapped in an invisible propose→refine→approve Refine Loop. Ideation is grounded through pairwise LLM-judge tournaments (Bradley–Terry/Elo) under co-evolutionary pressure; deployment realizes a per-tenant sovereign cell (its own repository, namespace, database, OAuth, and domain) federated to a shared control plane; a Pattern Learning Substrate reuses generalized architectural patterns behind an IP firewall. We deliver build-ready algorithm pseudocode, interface-level contracts, a contraction-mapping convergence model for the loop, and a correlated cost model. The contribution is an architecture — backend sealed, specified at the contract level — whose design aim is that autonomy and human authority compound rather than trade off. No empirical results are claimed.

Contributions

1. The Refine Loop — an invisible, branded propose→refine→approve planning loop at every stage, with a contraction-mapping convergence model.

2. Co-evolutionary grounded ideation — pairwise LLM-judge tournaments (Bradley–Terry/Elo) under Red Queen critic co-evolution, with a grounded fitness gate.

3. Verified deep grounded research — a STORM-style, retrieval-grounded thesis stage for web and mobile applications.

4. Sovereign white-label deployment — a per-tenant cell (own repository, namespace, database, OAuth, and domain) with edge-SSR brand resolution and horizontal autoscaling, federated to a shared control plane.

5. The Pattern Learning Substrate and IP firewall — generalized reuse of prior-platform patterns behind an anti-reproduction, cross-tenant-isolated firewall.

6. The interaction and design system — a full-screen chat + AG-UI artifact surface and a research-derived (non-dark) design system.

7. A cost and economics model — a correlated Monte-Carlo P&L and an Anthropic-frontier cost study (all figures illustrative).

Paper organization

The Refine Loop is developed first and independently (§7), since every later stage instantiates it. We then follow a venture through the pipeline: Catalyst grounds and ranks hypotheses; Thesis conducts human-steered research; Crucible provisions and ships the sovereign cell; Apex runs it live. Cross-cutting volumes specify the Unified Nexus Orchestrator (UNO) dispatch contract and platform primitives, the chat + AG-UI surfaces, the Pattern Learning Substrate and its firewall, and the economics model, before closing matter (threats to validity, related work, and a consolidated References volume). Volumes are self-contained and cross-referenced by label (e.g., "see §7"); primitives named here are defined once at first use and reused thereafter without restatement.

---

1. Introduction

Having an idea is cheap. Shipping it is not. Between a sentence a founder types into a chat box — "a compliance-tracking tool for Irish credit unions" — and a running product that a paying customer logs into lies a gauntlet: market validation, competitive research, a name, a brand, a data model, authentication, a payment path, infrastructure that survives a launch-day spike, a domain, a legal footing, and someone to keep the lights on. Conservatively, a small team crosses that gauntlet in something like nine months and a quarter of a million euro [illustrative]. Most ideas never make the crossing. They die not because they were wrong, but because the distance from hypothesis to hyper-scale is priced out of reach for almost everyone who has one.

This paper describes Nexus Axiom, a system that compresses that distance into a supervised conversation. A user brings a raw idea; the platform returns a live, horizontally-scaling, white-labelled product that the user owns — its own repository, its own Kubernetes namespace, its own database, its own OAuth realm, its own domain — with no trace of the platform that built it visible at first paint. The user is never asked to write code, provision a cluster, or read a Terraform plan. They are asked, repeatedly and at every consequential junction, one question: is this right?

That question is the load-bearing element of the whole design. We do not propose an autonomous founder-in-a-box. We propose the opposite: a fully instrumented builder that proposes constantly and decides never — a machine whose every output passes through a human gate before it becomes real.

1.1 Why existing automation stops at the doorstep

The last three years produced a remarkable stack of components, each of which solves a slice of the gauntlet, and none of which solves the crossing.

LLM agents can now decompose goals, call tools, criticise their own drafts, and coordinate in multi-agent ensembles. Reflexion showed that verbal self-feedback improves an agent across trials [Shinn 2023]; AutoGen framed application-building as multi-agent conversation [Wu 2023]; MetaGPT encoded software-company roles into a collaborative pipeline [Hong 2024]; generative agents demonstrated durable, believable behaviour over long horizons [Park 2023]. These systems are impressive planners. But an agent that plans to ship a product is not a product, and the literature is candid that unbounded autonomy accumulates error rather than shedding it.

Code generation has matured from function-completion to issue-resolution. Codex established that large models write useful code [Chen 2021]; AlphaCode reached competition-level program synthesis [Li 2022]; self-debugging closed part of the correctness gap [Chen 2023]; and SWE-bench made "resolve a real GitHub issue" a measurable task [Jimenez 2024], with SWE-agent showing that a purpose-built agent-computer interface lifts that number substantially [Yang 2024]. Yet a resolved issue is not a running business. None of these targets provisioning, tenancy, branding, scaling, or the operational surface a live customer touches.

Tool-use and generative UI let models reach outside themselves. Toolformer taught models to call APIs [Schick 2023]; ReAct interleaved reasoning and acting [Yao 2023]; Gorilla and ToolLLM scaled tool selection to thousands of real APIs [Patil 2023; Qin 2024]; Design2Code probed how far models can go from a mockup to a front-end [Si 2024]. This is the machinery behind an agent that can render an interface on demand — but rendering a screen is not standing up a sovereign, multi-tenant, auto-scaling deployment behind it.

Auto-app-builders — the commercial "describe an app, get an app" tools — come closest in ambition and fall shortest in three specific ways. They emit a monolith the vendor hosts, not an asset the customer owns. They stop at a demo, not a product that scales. And, trained to reproduce, they risk emitting verbatim fragments of their corpus — a hazard the memorization literature has quantified precisely: production models can be induced to regurgitate training data [Carlini 2021; Carlini 2023], with direct copyright implications [Karamolegkou 2023]. A venture builder that leaks another customer's code is not a venture builder; it is a liability.

Human-in-the-loop control is the thread that ties the critique together. Mixed-initiative interaction is an old and well-argued principle [Horvitz 1999], later distilled into concrete guidelines for human-AI systems [Amershi 2019]. Recent work puts humans explicitly inside software agents [Takerngsaksiri 2024], studies how a person should steer a multi-agent system rather than merely watch it [He 2026], and measures the trust a human actually extends to an LLM planner [Chen 2025] — trust that, the evidence suggests, is earned at the checkpoint, not asserted by the autonomy.

Each body of work is a component. The gap is that no published system, to our knowledge, unifies four things at once: grounded, competitive ideation that produces a defensible thesis rather than a plausible paragraph; verified deep research that cites its sources rather than hallucinating them; sovereign automated deployment that hands the customer a scaling, owned product rather than a hosted demo; and a human-gated refinement loop that binds all three so that nothing becomes real without approval. Nexus Axiom is our attempt to close exactly that gap.

1.2 Four gated stages, one spine

Nexus Axiom carries a venture through four stages, each gated by the human who owns it.

• Catalyst (Ideate). A raw idea is grounded against the market and a population of competing hypotheses, then evolved — not brainstormed once, but iterated under an immutable evaluation rubric and a co-evolutionary tournament (see §2).
• Thesis (Research). The surviving hypothesis is interrogated by a deep, retrieval-grounded research pipeline that reads the web (and mobile surfaces) and returns a cited dossier, not an unsupported claim (see §3).
• Crucible (Deploy). The thesis is compiled into a sovereign product: a per-tenant "cell" with its own namespace, repository, CI/CD, and brand-resolving edge — provisioned, not hand-built (see §4).
• Apex (Live). The product runs. It scales horizontally under load, it is monitored, and it can be re-entered to pivot — a new versioned turn of the same wheel, never a destructive overwrite (see §5).

The four stages are not the contribution. The spine that runs through all four is. Every stage — and every consequential step inside a stage — is wrapped in an invisible propose → refine → approve cycle we call the Refine Loop (developed in full in §7). The user experiences a conversation and a set of approvals. Underneath, each artifact is drafted, critiqued, and revised until it converges, and only then surfaced for a human decision. We model one turn of the loop as a state transition. Let $\mathcal{S}$ be the space of artifact states (an idea, a research dossier, a deploy manifest) under a semantic metric $d$, and let $R:\mathcal{S}\to\mathcal{S}$ be the composite propose-critique-revise operator. The loop iterates

and, when $R$ is a contraction with modulus $L<1$ — i.e. $d\!\left(R(x),R(y)\right)\le L\, d(x,y)$ — the Banach fixed-point theorem [Banach 1922] guarantees a unique $s^\star$ with $R(s^\star)=s^\star$ and a geometric convergence rate $d(s_k,s^\star)\le L^{k} d(s_0,s^\star)$. This is the same fixed-point structure that underlies deep equilibrium models [Bai 2019] and iterative self-refinement [Madaan 2023]; we make the contraction assumption explicit, argue when it holds, and place the human gate $G$ as the terminal acceptance operator, in §7 (the Refine Loop). The point for the introduction is only this: refinement here is a convergent process with a human at its terminus, not an open-ended agent loop.

The top-level control flow makes the spine literal:

Plain Text
12 lines
Copy
Algorithm 1  Venture lifecycle under human-gated Refine Loops
Input:  raw idea i0 from user u; organization (sovereign cell) org
Output: live sovereign product P, or a clean halt at any gate
 1.  cat  <- RefineLoop(Catalyst, i0,  gate = u)     // Ideate
 2.  if not Approved(cat):  return HALT
 3.  the  <- RefineLoop(Thesis,   cat, gate = u)     // Research
 4.  if not Approved(the):  return HALT
 5.  P    <- RefineLoop(Crucible, the, gate = u)     // Deploy sovereign cell
 6.  if not Approved(P):    return HALT
 7.  while P is live:                                 // Apex
 8.      P <- RefineLoop(Apex, P, gate = u)          // operate, monitor, pivot
 9.  return P

RefineLoop is the invisible engine; Approved is the human gate. A halt at any gate is a first-class outcome, not a failure — the user can stop, and stopping costs nothing downstream.

1.3 Grounding: plugin independence

Nexus Axiom is not a greenfield abstraction. It is built on the Adverant plugin-independence thesis: keep the brain shared, make everything the customer touches sovereign. The shared control plane — memory, orchestration policy, the pattern substrate — is a sealed asset that every venture draws on but none can see into or contaminate. Everything else is the customer's: its own repository on the venture forge, its own namespace and database, its own OAuth, its own domain. The two are joined by a thin federation edge, not a shared runtime.

Concretely, all work — ideation, research, a deploy step, a live action — enters the platform through a single dispatch contract. The Unified Nexus Orchestrator (UNO) exposes one entrypoint, POST /api/v1/dispatch, resolves the requested skill through a five-gate pre-execution broker (classification, data-residency, export-class, spend, safety), and enqueues the work for the sole executor. The request that threads a run across the chat panel, the progress dock, and the artifact pane is the tenant boundary made concrete:

TypeScript
15 lines
Copy
// The four human-gated stages a venture moves through.
type Stage = 'catalyst' | 'thesis' | 'crucible' | 'apex';

// Every unit of work enters through one contract (UNO: POST /api/v1/dispatch).
// organizationId is the sovereign boundary: one tenant, one cell.
interface DispatchRequest {
  jobType: string;                    // resolves to a skill in the 5-gate broker
  organizationId: string;             // the tenant — the sovereign cell
  userId: string;                     // the human standing at the gate
  inputParams: Record<string, unknown>;
  appId: string;                      // the venture being built
  pluginId?: string;
  sessionId: string;
  correlationId: string;              // threads one run across chat, PCC, artifacts
}

The customer-facing surface is a shared vocabulary of primitives — a dockable unified chat, an AG-UI artifact pane, a cross-plugin Progress Command Center, an inspector of declarative K-cards — each of which we treat strictly at the interface level; the backend behind dispatch remains a black box throughout this paper. Multi-tenancy here is not a convenience but the product: a per-tenant cell is the strong-isolation end of the well-studied silo-pool-bridge spectrum [Chong 2006; Ochei 2018; Kumar 2026], and the horizontal scale that makes "hyper-scale" more than a slogan is the standard, measurable machinery of Kubernetes autoscaling — reactive HPA and queue-driven KEDA scaling [Ahmad 2024; Pilyai 2023] — wired in at provision time (see §4).

Two design commitments deserve early statement because they constrain everything that follows. First, ideation and research are grounded in retrieval, not recollection: the research pipeline is built in the STORM/RAG lineage [Lewis 2020; Shao 2024] over a graph-structured memory [Edge 2024], so claims carry citations by construction (see §3). Second, generation draws on a Pattern Learning Substrate that indexes the architecture of prior Adverant platforms into GraphRAG and reuses only generalized patterns behind an IP firewall — never verbatim proprietary or cross-customer source (see §8, the Pattern Substrate) — a discipline the memorization literature shows is not optional [Carlini 2023].

1.4 Contributions

We restate the paper's contributions in brief; each is developed later in the paper.

1. The Refine Loop — an invisible, branded propose→refine→approve planning loop at every stage, with a contraction-mapping convergence model.
2. Co-evolutionary grounded ideation — pairwise LLM-judge tournaments (Bradley–Terry/Elo) under Red Queen critic co-evolution, with a grounded fitness gate.
3. Verified deep grounded research — a STORM-style, retrieval-grounded thesis stage for web and mobile applications.
4. Sovereign white-label deployment — a per-tenant cell (own repository, namespace, database, OAuth, and domain) with edge-SSR brand resolution and horizontal autoscaling, federated to a shared control plane.
5. The Pattern Learning Substrate and IP firewall — generalized reuse of prior-platform patterns behind an anti-reproduction, cross-tenant-isolated firewall.
6. The interaction and design system — a full-screen chat + AG-UI artifact surface and a research-derived (non-dark) design system.
7. A cost and economics model — a correlated Monte-Carlo P&L and an Anthropic-frontier cost study (all figures illustrative).

We claim no empirical results. This is an architecture, methodology, and theory paper; every hypothetical figure is tagged [illustrative], and the platform's backend is treated as a sealed boundary.

1.5 Roadmap

The paper proceeds as follows. §2 develops co-evolutionary grounded ideation and the evaluation rubric. §3 details the deep-research pipeline. §4 specifies the sovereign deploy and the interaction architecture. §5 covers the live product, re-entry, and versioned pivots. §6 derives the design-psychology and UI/UX system from evidence. §7 is the flagship treatment of the Refine Loop, including the convergence analysis previewed above. §8 presents the Pattern Learning Substrate and IP firewall. §9 enumerates the per-venture deliverable artifact library; §10 and §11 cover economics, GTM, and cost/pricing; §12 the patent portfolio; §13 the UI/UX compendium; §14 discussion, limitations, and compliance; and the References gather the verified sources and implementation appendices. A reader who wants the single idea before the full machinery should read §7 (the Refine Loop) first: everything else is what that loop is asked to build.

---

2. Methodology I — Co-evolutionary Grounded Ideation

The Catalyst stage does not "brainstorm." It runs a search. A raw idea enters as a seed; what leaves the stage — subject to the human gate that closes every Nexus Axiom loop (see §7, the Refine Loop) — is not a single polished pitch but a ranked, diverse portfolio of venture hypotheses, each one already bruised by adversarial critique and anchored to retrieved evidence. This volume gives the mathematics. We formalize the candidate population, the pairwise LLM-judge tournament that ranks it, the Red Queen co-evolution that keeps it honest, and the fixed-point argument that says the whole thing settles. Generation and research are not two phases here. They interleave: every candidate is stress-tested, in the same round it is born, against the grounded corpus produced by the Deep Grounded Research pipeline (see §3). Ideation is grounded, or it is nothing.

Provider routing is not incidental to the method. Catalyst and the research substrate it consumes are pinned to frontier Anthropic models at maximum thinking budget; the policy tier used by later stages is deliberately excluded here, because the ranking signal degrades faster than any other quantity in the pipeline when the judge is weak.

2.1 The candidate population and its fitness

Let $\mathcal{I}$ denote the (unbounded, structured) space of venture hypotheses. A single candidate $c \in \mathcal{I}$ is not a sentence; it is a typed object — a hypothesis statement, an ideal-customer profile, a value proposition, a wedge, a monetization path, a falsifiable risk. At round $t$ the stage maintains a finite population

Each candidate is evaluated against a grounded evidence set $G_t$ — the current retrieval frontier from §3 — by the immutable rubric served by EvaluatorService. That rubric is a fixed platform primitive, not a tunable knob: five dimensions, each scored on $[0,20]$, summed to a total on $[0,100]$,

with $d$ ranging over Relevance, Accuracy, Depth, Coherence, Actionability. Define the normalized fitness

and the hard survival gate that the rubric itself emits,

The threshold $60$ is not chosen here; it is the fixed contract of the evaluator (Section 2.6 shows why a fixed gate matters for convergence). Absolute scores are the anchor, but they are known to be miscalibrated and drifty when produced by an LLM judge in isolation [Liu 2023]. So the anchor is never the ranking. Ranking comes from comparison.

2.2 The pairwise LLM-judge tournament

We rank candidates by pairwise preference, the regime in which LLM judges are most reliable and most defensible [Zheng 2023, Chiang 2024]. A judge model $J$ — a different model family from the generator, for reasons made precise below — receives an ordered pair $(c_i, c_j)$ together with the grounded context $G_t$, and emits a preference. Let

A tournament schedule $\mathcal{S} \subseteq \{(i,j): i<j\}$ selects which pairs are compared; the outcome of round $t$ is a set of directed win/loss edges over $P_t$.

The three biases, and how the schedule cancels them. LLM judges are not neutral instruments. Three failure modes dominate the literature and each has a mechanical mitigation baked into $\mathcal{S}$:

1. Position bias — the judge favors whichever candidate appears first (or second) irrespective of content [Wang 2023]. Mitigation: every unordered pair is scored in both orders, $(c_i,c_j)$ and $(c_j,c_i)$, and a preference counts only if it is order-consistent. Define the debiased indicator

so a flip between the two orderings contributes $W_{ij}=\tfrac12$ — an explicit tie — rather than a phantom win.

2. Verbosity bias — longer candidates win for being longer, not better [Dubois 2024]. Mitigation: length-controlled prompting and a length penalty applied to the candidate rendering before the judge sees it, so token count carries no signal.

3. Self-enhancement bias — a judge prefers outputs from its own model family [Zheng 2023]. Mitigation: the judge family is disjoint from the generator family, and the rubric-anchored prompt forces the judge to justify each dimension against $G_t$ before committing a preference, converting a vibe into a grounded argument.

The order-swap and length controls are cheap and they matter: an unmitigated pairwise judge produces a ranking whose top rank is a function of prompt order, which is to say, noise.

2.3 From comparisons to strengths: Bradley–Terry

Pairwise edges are a graph; we need a scalar strength per candidate. The Bradley–Terry model [Bradley 1952] assigns each candidate a latent positive strength $\pi_i > 0$ and posits

Write $\pi_i = e^{\beta_i}$ so that $P(i\succ j) = \sigma(\beta_i - \beta_j)$ with $\sigma$ the logistic function; strengths are identified only up to a shared additive constant on $\beta$, so we fix a gauge (e.g. $\sum_i \pi_i = 1$, the sum-to-one normalization the MM update below applies). Given the debiased tallies — let $w_i = \sum_{j\ne i} (\text{wins of } i \text{ over } j)$ and $n_{ij}$ the number of $i$–$j$ comparisons — the log-likelihood is

where $a_{ij}$ counts $i$'s wins over $j$. This is concave in $\beta$ but has no closed form. We fit it with the minorization–maximization (MM) algorithm of [Hunter 2004], which replaces the awkward $\log(\pi_i+\pi_j)$ term with a tangent linear minorizer and yields the clean multiplicative update

Each MM step provably does not decrease $\ell$, so the iteration converges to the unique MLE whenever the comparison graph is connected — a condition the schedule $\mathcal{S}$ enforces by never leaving a candidate un-compared. MM is preferred over Newton here because it needs no Hessian, no step size, and cannot overshoot; for populations of the size Catalyst carries it converges in a handful of sweeps.

2.4 Streaming ranks: the Elo update and its BT identity

Tournaments arrive incrementally — candidates are generated, compared, mutated, re-compared — so we also maintain an online rating that updates per comparison without refitting the whole graph. This is Elo [Elo 1978]. Each candidate carries a rating $R_i$; after a comparison with observed outcome $S_{ij}\in\{0,\tfrac12,1\}$ (the debiased $W_{ij}$ of Section 2.2 supplies $S$), the update is

with $K$ the step size (we use $K=24$ [illustrative], annealed downward as a candidate accumulates games so early volatility does not fossilize into a wrong rank). Elo is not a different model from Bradley–Terry; it is BT's online estimator. Substituting the reparam $\pi_i = 10^{R_i/400}$ into the BT win probability gives

so the Elo expected score is the Bradley–Terry probability. We use MM (Section 2.3) for a periodic batch re-fit that removes path-dependence, and Elo between re-fits for cheap streaming order. One caveat we respect operationally: Elo ratings are sensitive to comparison order and to the specific set of opponents, and small pools inflate apparent separations [Boubdir 2024]. The mitigations are permutation-averaged seeding of the schedule and reporting rank bands, not point ratings, to the human at the gate — a candidate that is rank 3 in one seed and rank 6 in another is presented as "top-tier, unstable," never as a false-precision "#3."

2.5 The Red Queen: generators versus critics as co-evolving populations

A tournament ranks what exists. It does not manufacture pressure to improve. That pressure comes from a second population. Alongside the generators we run a population of adversarial critics $A_t = \{a_1, \dots, a_m\}$ — each critic is a structured attack: a failure hypothesis, a market objection, a "why this dies in month nine," a substitute nobody costed. Critics do not score candidates on the rubric; they try to break them. This is a co-evolutionary arms race in the sense of [Bansal 2017]: emergent complexity comes not from a fixed objective but from two populations each escalating in response to the other. The name is apt — like the Red Queen, both sides must keep running to stay in the same place.

Adversarial-discounted fitness. A candidate's grounded rubric fitness $f(c)$ is discounted by how well the current critics defeat it. For critic $a_k$ let $p_k(c)\in[0,1]$ be the probability — estimated by the judge $J$, grounded in $G_t$ — that $a_k$'s failure hypothesis holds against $c$, and let $\sigma_k\in[0,1]$ be its severity weight (the critic-severity $\sigma_k$ is distinct from the logistic $\sigma$ of Section 2.3; the subscript $k$ disambiguates). Define the effective fitness

A candidate that scores $85/100$ on the rubric but is shredded by a high-severity, high-probability critic collapses toward the survival line; a candidate that survives every live attack keeps nearly all of its grounded fitness. Survival at round $t$ requires both the immutable gate and the adversarial floor,

with $\tau$ an adversarial-survival threshold [illustrative]. Critic fitness is the mirror image: a critic is rewarded exactly when it lowers the effective fitness of otherwise-strong candidates,

so critics that only attack candidates that were already dead earn nothing, and critics that puncture the front-runners earn the most. This is the QDAIF pattern of [Bradley 2023]: the LLM is the fitness evaluator for both populations, closing the loop without a hand-coded objective.

Arms-race dynamics. Model the mix of generator strategies by frequencies x \in \Delta^{n-1}\ and critic strategies by $y \in \Delta^{m-1}$, with generator payoff matrix$A$and critic payoff matrix$B$. The two-population replicator dynamics are

When the interaction is near zero-sum ($B \approx -A^\top$) — which is precisely the generator/critic relationship, one side's gain is the other's loss — the interior admits no static evolutionarily stable state, and the trajectories cycle or drift persistently. That non-convergence is a feature. It is the engine of open-endedness [Hughes 2024, Openendedlearningteam 2021]: the target keeps moving, so the generators keep discovering, and the system does not fossilize on the first locally-good idea. The paired open-ended structure — co-generate a challenge and a solver, advance only when a minimal criterion is met — is exactly POET's construction [Wang 2019], transplanted from environments-and-agents to critiques-and-ventures.

Keeping the portfolio diverse: MAP-Elites. An arms race left alone will happily collapse all generators onto one lineage. We prevent that with a quality-diversity archive in the style of MAP-Elites [Mouret 2015]. Define a behavior descriptor $b(c) \in \mathcal{B}$ that projects a candidate onto a low-dimensional map of what kind of venture it is — e.g. (market segment) $\times$ (business model) $\times$ (go-to-market motion), discretized into cells [illustrative]. The archive $\mathcal{A}$ holds, in each occupied cell, the highest-$F$ candidate seen for that cell:

New candidates only displace the incumbent of their own cell, and only on strict improvement. The output of Catalyst is this archive — an illuminated map of distinct, individually-strong ventures — not a scalar winner. That is what gets handed to the human gate: a portfolio, ranked within cells by Bradley–Terry strength, diverse across cells by construction.

2.6 Why generation and grounding are one step

It is tempting to read Catalyst (generate) and §3 (research) as sequential. They are not. The judge $J$ never sees a candidate without $G_t$; the critics mine $G_t$ for their failure hypotheses; the rubric's Accuracy and Depth dimensions are defined against retrieved evidence. A candidate that cannot be grounded scores low on Accuracy, fails the gate, and dies in the same round it was proposed. Concretely, each generation round issues retrieval queries derived from the live population's weaknesses (the weaknesses array the evaluator returns is a retrieval prompt in disguise), so $G_{t+1}$ is shaped by what the current candidates got wrong. Generation pulls research; research reshapes generation. The two populations of Section 2.5 both feed on the same growing evidence set, which is why we call the method grounded co-evolution rather than co-evolution with a research bolt-on.

2.7 The co-evolutionary grounded-ideation loop

Plain Text
33 lines
Copy
Algorithm 1: Co-evolutionary Grounded Ideation (one Catalyst cycle)
Inputs:  seed idea z; grounding interface G (§3); judge model J (Anthropic, max-think);
         generator model Gen; OptimizerService O; EvaluatorService E (immutable rubric);
         archive A (empty); rounds T; survival threshold tau; Elo step K
Output:  quality-diversity archive A of surviving venture hypotheses (ranked)

 1  P <- Gen.expand(z, k = n)                 # seed an initial candidate population
 2  Acrit <- Gen.criticize(z, k = m)          # seed an initial critic population
 3  for each c in P: R[c] <- 1200             # initial Elo ratings [illustrative]
 4  for t = 1 .. T do
 5      G_t <- G.retrieve(queries_from_weaknesses(P))     # grounding is refreshed per round
 6      # --- evaluate: immutable rubric, grounded ---
 7      for each c in P do
 8          E_c <- E.score(c, G_t)            # {score, reasoning, strengths, weaknesses, keep}
 9          f[c] <- E_c.score / 100
10      # --- adversarial discount ---
11      for each c in P do
12          F[c] <- f[c] * PROD over a in Acrit of (1 - severity(a) * p(J, a, c, G_t))
13      # --- pairwise tournament (order-swapped, length-controlled) ---
14      for each scheduled pair (c_i, c_j) in Schedule(P) do
15          S <- debiased_preference(J, c_i, c_j, G_t)     # both orders; ties on flip
16          R[c_i] += K*(S      - E_elo(R[c_i],R[c_j]))
17          R[c_j] += K*((1-S)  - E_elo(R[c_j],R[c_i]))
18      pi <- MM_BradleyTerry(win_counts, pair_counts)     # periodic batch re-fit
19      # --- selection into the quality-diversity archive ---
20      for each c in P with keep(c) and F[c] >= tau do
21          b <- descriptor(c)
22          if A[b] is empty or F[c] > F[A[b]]: A[b] <- c
23      # --- co-evolve both populations via the SAME mutation operator ---
24      P     <- O.mutate(top_by(pi, P),   objective = "raise grounded fitness")
25      Acrit <- O.mutate(top_by(g, Acrit),objective = "defeat surviving candidates")
26      if human_waitpoint_reached(t): pause for approval    # see §7
27  return rank_within_cells(A, pi)

Two design commitments are visible in the pseudocode. First, the same OptimizerService refine/mutate operator drives both populations (lines 24–25); the only difference is the objective handed to it — raise grounded fitness, or defeat survivors. Second, human waitpoints (line 26) are first-class: the loop is engineered to pause, surface the archive, and resume on approval, which is the invisible propose→refine→approve contract detailed in §7. Reflexion-style verbal critique [Shinn 2023] is the substrate for the critic mutation — a critic improves by reflecting, in language, on which of its past attacks landed.

2.8 Convergence

Co-evolution (Section 2.5) is deliberately non-stationary, so we are careful about what converges. We separate two timescales.

Inner loop (fixed grounding, fixed judge) — a contraction. Hold $G_t$ and $J$ fixed and consider the refine map $T$ that sends an ensemble of candidates to its once-refined successor via OptimizerService (this is Self-Refine applied to a population [Madaan 2023]). Represent an ensemble as a distribution $P$ over the candidate embedding space and equip that space with a metric $d$ (Wasserstein over embeddings, or total variation over the archive). Assume $T$ is $\gamma$-Lipschitz,

which holds when the mutation operator's step is bounded and the judge's preference is $L$-smooth in the embedding — mild conditions the length/position controls of Section 2.2 help enforce. Then $T$ is a contraction on a complete metric space, and the Banach fixed-point theorem [Banach 1922] gives a unique fixed point $P^\star$ with geometric convergence

This is the same equilibrium framing that underwrites deep equilibrium models [Bai 2019] and equilibrium-sequence planning [Li 2025], and that iterative pipeline-refinement methods exploit empirically [Xue 2025]: refinement under a fixed evaluator has a fixed point, and it is reached at a geometric rate.

Outer loop (evolving critics) — monotone bounded improvement. The critics move, so the inner fixed point moves with them; there is no single global $P^\star$ across the whole run, and by design there should not be. What is guaranteed is that the archive's elite frontier is monotone. Line 22 replaces an incumbent only on strict improvement in $F$, and F(c) \le f(c) \le 1\ is bounded above. Define the frontier value $V_t = \sum_{b} F(\mathcal{A}t[b])$. Here each cell stores the *insertion-time* effective fitness of its occupant (standard MAP-Elites bookkeeping), so$V_t$sums per-cell values that are frozen when written and can only rise when the strict-improvement test of line 22 replaces an incumbent — monotone by construction. The caveat is that$V\infty$then aggregates fitnesses measured against *different* critic generations, so it is a bookkeeping monotone, not a claim of quality against the final adversary. Then$V_t$ is non-decreasing and bounded, hence convergent by the monotone convergence theorem:

So the co-evolution never regresses the portfolio even as it keeps stirring the candidates. The fixed gate of Section 2.1 is what makes this clean: because $\mathrm{keep}$ and the rubric are immutable, the ordering $F$ is stable across rounds and monotonicity is well-defined. A drifting evaluator would make "improvement" meaningless; the immutable rubric is not a bureaucratic constraint but the mathematical precondition for convergence. In practice the human gate (§7), not an $\varepsilon$-stopping rule, decides when $V_t$ has plateaued enough to freeze the archive and advance to Thesis.

2.9 Coding patterns

The interfaces below are illustrative and interface-level; the backend remains a black box and no proprietary source is reproduced. EvaluatorResult mirrors the immutable rubric contract; the remaining functions realize Sections 2.4, 2.2, and 2.5.

TypeScript
25 lines
Copy
// The immutable evaluator contract (5 dims x 20 pts = 0..100; keep = score >= 60).
interface EvaluatorResult {
  score: number;                 // 0..100, sum of the five dimensions
  dimensions: {                  // each 0..20, in fixed order
    relevance: number;
    accuracy: number;
    depth: number;
    coherence: number;
    actionability: number;
  };
  reasoning: string;             // 2-3 sentence grounded assessment
  strengths: string[];
  weaknesses: string[];          // doubles as the next round's retrieval prompt
  keep: boolean;                 // score >= 60
}

// A venture candidate and its live ranking state.
interface Candidate {
  id: string;
  hypothesis: string;
  descriptor: [string, string, string];   // MAP-Elites cell: (segment, model, motion)
  elo: number;                             // online rating (Section 2.4)
  f: number;                               // grounded rubric fitness in [0,1]
  fEff: number;                            // adversarial-discounted fitness F(c)
}

TypeScript
11 lines
Copy
// Elo online update. E is the Bradley-Terry win probability (Section 2.4).
function expectedScore(rA: number, rB: number): number {
  return 1 / (1 + Math.pow(10, (rB - rA) / 400));
}

function eloUpdate(rA: number, rB: number, sA: number, K = 24 /* illustrative */): [number, number] {
  const eA = expectedScore(rA, rB);
  const rA2 = rA + K * (sA - eA);
  const rB2 = rB + K * ((1 - sA) - (1 - eA));   // symmetric, zero-sum outcome
  return [rA2, rB2];
}

TypeScript
11 lines
Copy
// One debiased pairwise tournament comparison: both orders, length-controlled,
// cross-family judge. Returns S in {0, 0.5, 1} for candidate a (Section 2.2).
async function debiasedPreference(
  J: JudgeModel, a: Candidate, b: Candidate, G: GroundingContext,
): Promise<number> {
  const ab = await J.prefer(render(a), render(b), G);   // render() length-normalizes
  const ba = await J.prefer(render(b), render(a), G);
  const aWinsAB = ab === "first" ? 1 : 0;
  const aWinsBA = ba === "second" ? 1 : 0;
  return (aWinsAB + aWinsBA) / 2;                        // order-flip => 0.5 (explicit tie)
}

TypeScript
13 lines
Copy
// Critic mutation via the OptimizerService refine/mutate operator (Section 2.7, line 25).
// The generator population uses the SAME call with a different objective.
async function evolveCritics(
  O: OptimizerService, critics: Critic[], survivors: Candidate[], G: GroundingContext,
): Promise<Critic[]> {
  const elite = topBy(critics, (a) => criticFitness(a, survivors, G));  // g(a_k), Section 2.5
  return O.mutate({
    population: elite,
    objective: "defeat surviving candidates",   // vs. "raise grounded fitness" for generators
    grounding: G,
    operator: "refine",                          // Reflexion-style verbal self-critique
  });
}

2.10 What Catalyst hands forward

The stage terminates — at a human waitpoint, never autonomously — with a quality-diversity archive: a small map of venture hypotheses, each surviving the immutable gate and the adversarial floor, ranked within its cell by Bradley–Terry strength, diverse across cells by the MAP-Elites construction, and every claim inside each hypothesis traceable to $G_t$. No number in that archive is fabricated; the "—" convention of the inspector surface (see §4) applies from the first round, so an unsupported figure is rendered as absent, not invented. The chosen hypothesis flows into Thesis, where Deep Grounded Research (§3) turns the surviving skeleton into a defensible dossier — carrying with it the retrieval frontier $G_t$ that Catalyst already built, so no grounding work is repeated. The tournament, the critics, and the archive do not stop at the stage boundary; they are the same co-evolutionary machinery the Refine Loop (§7) runs, invisibly, underneath every subsequent stage of the build.

---

3. Methodology II — Deep Grounded Research

The winning idea leaves Catalyst as a hypothesis (see §2, Ideation). Thesis is where it earns the right to be built. This is the second human-gated stage, and its single obligation is severe: turn a promising direction into an evidence-grounded thesis in which every load-bearing claim is traceable to a retrievable source. No parametric assertion survives on the model's word alone. If the platform cannot ground a claim, the platform does not make it — it renders the gap, the way a k-card renders a missing value as "—" rather than inventing one.

The engine is the real nexus-autoresearch pipeline, dispatched through UNO like every other action, and pinned — for this stage and Catalyst only — to frontier Anthropic models at maximum thinking. What follows specifies how that pipeline is instantiated for a venture whose surface is a business web application and one or more native mobile apps (iOS, Android), and how the zero-hallucination contract is enforced end to end.

3.1 Why multi-perspective retrieval, not a single agent

A single research agent answering a single query inherits the failure mode of the underlying model: it fills gaps with plausible fabrication. Retrieval-augmented generation attacks this directly by conditioning generation on retrieved evidence [Lewis 2020], and the design space around it — chunking, re-ranking, query rewriting, active retrieval, self-critique — is now large enough to warrant its own survey [Gao 2023]. But retrieval alone does not guarantee coverage. A naive RAG loop retrieves what the first query happens to match, and a venture thesis has many facets that no first query touches.

STORM is the answer we adopt for breadth [Shao 2024]. Its insight: simulate a set of expert perspectives, let each perspective ask its own questions, and the union of those question threads covers far more of the topic than any monolithic prompt. Nexus Axiom runs the perspective-guided variant with a human seat at the table, following co-STORM's participatory roundtable [Jiang 2024] — the user is not a spectator to the research, they are a perspective in it, and the Thesis gate (§3.6) is where that participation becomes decisive.

3.2 The pipeline, mapped to real services

The abstract STORM loop maps one-to-one onto the deployed nexus-autoresearch services.

• AnalysisService classifies the request and emits a structured plan header: a requestType (e.g. competitive_analysis, literature_review), a complexity in $[1,10]$, an estimatedTokens budget, a subTaskCount, and — the load-bearing field — a set of 2–6 expert perspectives. Complexity scales subTaskCount: simple requests decompose into 2–3 sub-questions, very complex ones into 20–50.

• PlannerService performs the STORM-style decomposition proper. Given the analysis, it produces sub-questions, each tagged with the perspective that owns it, plus a dependency DAG. Its bias is explicit and correct: prefer breadth over depth — more independent questions beat long dependency chains. Independent questions parallelize; a dependency edge is created only when a question genuinely cannot be answered before another completes.

• RetrieverService grounds each sub-question against three channels: the open web (via MageAgent orchestration), the graph substrate (semantic search over nexus-graphrag, also the fallback when web orchestration fails), and tenant-supplied files (via FileProcess). Every returned unit carries sourceType, an optional url, a relevanceScore, and a contentHash — provenance is not bolted on later, it is native to the retrieval result.

• EvaluatorService applies an immutable rubric — a hardcoded system prompt the agent cannot modify — scoring output across five dimensions at 20 points each: Relevance, Accuracy, Depth, Coherence, Actionability. It returns {score, reasoning, strengths, weaknesses, keep}, where $\text{keep} = \mathbb{1}[\text{score} \ge 60]$. The immutability matters: it is a prompt-injection firewall. Retrieved content that contains instructions to the evaluator is ignored by construction.

• AggregatorService composes the kept findings into the thesis, and OptimizerService is the refine/mutate operator — when the evaluator flags a weak dimension, the optimizer re-queries the weak cells rather than the whole thesis.

Between these stages sit human waitpoints — the pipeline can pause and surface intermediate state for approval before it spends the next tranche of frontier tokens. The Thesis gate is the terminal waitpoint, and it is a Refine Loop (see §7, the Refine Loop).

3.3 Grounding over a graph, not just a corpus

Flat retrieval answers local questions well and global questions badly. "What does this API cost?" is local; "how does this whole market cohere?" is global, and a query-focused summary over community structure answers it far better than top-$k$ chunks [Edge 2024]. Nexus Axiom therefore retrieves over both a flat index and the CMA graph served by nexus-graphrag.

The graph-RAG literature we lean on is deliberately plural. HippoRAG's neurobiologically-inspired indexing gives cheap multi-hop association across documents [Gutierrez 2024]; LightRAG contributes a dual-level, incremental graph index that keeps retrieval fast as the tenant's evidence base grows [Guo 2024]; Think-on-Graph treats the LLM as an agent that traverses the graph, interleaving reasoning with hops so that a chain of evidence, not a single passage, backs a conclusion [Sun 2024]; and G-Retriever formalizes retrieval over textual graphs for exactly this question-answering-over-structure setting [He 2024]. The retrieve-then-reason-then-retrieve-again cadence is the ReAct pattern [Yao 2023], and two refinements make it grounded rather than merely active: FLARE anticipates when the next retrieval is needed and fires it before generating past the edge of its evidence [Jiang 2023], and Self-RAG learns to interleave retrieval with self-critique, emitting reflection on whether a span is supported [Asai 2023]. Our EvaluatorService is the deployed analog of that critique step — externalized, immutable, and auditable rather than learned into the weights.

3.4 Grounding the mobile domain

A venture that ships a native app lives or dies on constraints that never appear in generic market research, so the perspective set is specialized when the tenant's target platforms include ios or android. Concretely, the analysis stage is seeded with mobile-native viewpoints: a platform-review perspective (App Store Review Guidelines, Google Play policy — the questions that decide whether the app can exist), a capability perspective (push, biometrics, in-app purchase economics, background execution, permission surfaces), an ASO/growth perspective (store-listing discoverability, category dynamics), a fragmentation perspective (OS-version and device spread on Android; deprecation cadence on iOS), and a privacy perspective (App Tracking Transparency, data-safety declarations, regional residency).

Each mobile claim must resolve to a retrievable artifact — a guideline clause, an API reference, a platform changelog — not to the model's recollection of one. This is where provenance freshness earns its keep. Store policy and OS capability are moving targets; a source retrieved eighteen months ago may now be wrong. So every Source carries a retrievedAt timestamp, and the aggregator down-weights or flags stale evidence rather than treating age as irrelevant. The output of this stage is what makes the Crucible code-generation (§4) buildable and compliant: the app is grounded before a line of it is composed from the pattern substrate (§8).

3.5 The zero-hallucination contract in code

Grounding is a data-model commitment, not a prompt. A Finding is one atomic, checkable claim; it carries the exact source set it rests on; and its confidence is computed from those sources, never asserted. The following pattern extends the real RetrievalResult shape with the fields the contract requires.

TypeScript
37 lines
Copy
// Provenance-carrying units. `Source` extends the real RetrieverService
// RetrievalResult (web via MageAgent, graph via nexus-graphrag, files via
// FileProcess); `Finding` is the atomic, source-backed unit of a thesis.
type SourceChannel = 'web' | 'graph' | 'tenant-file' | 'store-policy' | 'api-ref';

interface Source {
  id: string;               // stable contentHash — dedup + audit trail
  channel: SourceChannel;
  title?: string;
  url?: string;             // resolvable locator when the source is public
  retrievedAt: string;      // ISO-8601; freshness for moving targets (ASO, store rules)
  reliability: number;      // r_s ∈ [0,1] — channel/domain prior
  relevance: number;        // m_s ∈ [0,1] — query-match score from retrieval
  quotedSpan: string;       // the exact text the claim rests on (no paraphrase drift)
  platform?: 'ios' | 'android' | 'web';   // set for mobile-domain evidence
}

type FindingStatus = 'admissible' | 'unverified';

interface Finding {
  id: string;
  perspective: string;      // the STORM viewpoint that produced it
  question: string;         // the sub-question answered
  claim: string;            // one atomic, checkable assertion
  sources: Source[];        // S(f) — never empty for an admissible finding
  confidence: number;       // noisy-OR over sources ∈ [0,1] (formula below)
  status: FindingStatus;
  supersedes?: string;      // prior finding id — for re-entry / versioned thesis
}

// The honesty contract, in code: a claim with no grounding cannot be emitted
// as fact. It is retained as 'unverified' and rendered as an explicit gap —
// exactly as a k-card shows a missing value "—" instead of fabricating one.
function admit(f: Omit<Finding, 'status'>, tau: number): Finding {
  const grounded = f.sources.length > 0 && f.confidence >= tau;
  return { ...f, status: grounded ? 'admissible' : 'unverified' };
}

The confidence field is not a vibe. Let a finding $f$ be supported by sources $S(f)$, each source $s$ carrying reliability $r_s \in [0,1]$ (a channel/domain prior) and relevance $m_s \in [0,1]$ (the retrieval match score). Treating sources as conditionally independent evidence, confidence is a noisy-OR:

A single weak source yields low $c(f)$; agreement across several independent, reliable, on-point sources drives it toward $1$. A finding is admissible iff it clears both the grounding predicate and a confidence floor $\tau$:

At the thesis level, define grounding coverage over the set of emitted claims $\mathcal{C}$:

The zero-hallucination target is $\rho = 1$ for everything the thesis asserts as fact. Non-admissible findings are not deleted — they are retained as unverified and surfaced as explicit open questions, which is precisely the material the user tends to refine at the gate.

3.6 The grounded-research algorithm

Plain Text
30 lines
Copy
Algorithm 1  GROUNDED-THESIS(I, T, waitpoints)
Input:  winning idea I from Catalyst (see §2);
        tenant context T = (domain, platforms ⊆ {web, iOS, Android}, residencyPolicy);
        confidence floor τ, evaluator keep threshold 60, retry budget k.
Output: approved Thesis Θ — admissible, source-backed Findings + open questions.

 1  A ← Analyze(I, T)                 # requestType, complexity∈[1,10],
                                      # perspectives P (2..6), subTaskCount
 2  P ← P ∪ MobilePerspectives(T)     # seed platform-review/ASO/privacy iff mobile
 3  (Q, G) ← Plan(I, A)               # STORM decomposition → sub-questions Q,
                                      # dependency DAG G; prefer breadth
 4  F ← ∅
 5  for each perspective p ∈ P in parallel do
 6      for each q ∈ Q with owner(q)=p, in topological order of G do
 7          Cands ← Retrieve(q, T)    # web (MageAgent) ∪ graph (GraphRAG) ∪ files
                                      #   respecting T.residencyPolicy at the UNO gate
 8          if UnderCovered(q, Cands) then                 # active retrieval …
 9              Cands ← Cands ∪ Retrieve(Reformulate(q), T)  # … FLARE-style re-query
10          f ← Synthesize(q, Cands)  # atomic claim + supporting source set S(f)
11          f.confidence ← 1 − Π_{s∈S(f)} (1 − r_s·m_s)   # noisy-OR
12          f.status ← admissible(f, τ) ? 'admissible' : 'unverified'
13          F ← F ∪ {f}
14  E ← Evaluate(F)                   # IMMUTABLE 5-dim rubric, score ∈ [0,100]
15  attempts ← 0
16  while E.score < 60 and attempts < k do          # keep gate
17      F ← Optimize(F, E.weaknesses) # targeted re-query of the weak cells only
18      E ← Evaluate(F); attempts ← attempts + 1
19  Θ ← Aggregate(F)                  # facts ← admissible only; gaps ← unverified
20  Θ ← RefineLoop(Θ, waitpoints)     # propose → refine → approve (see §7)
21  return Θ

Two properties are worth stating plainly. First, admissibility (line 12) is checked before aggregation, so an unsupported claim can never be laundered into the thesis by a downstream stage — the gap is carried forward as a gap. Second, the keep loop (lines 16–18) is bounded and targeted: the optimizer mutates only the dimensions the immutable evaluator marked weak, which is why a thesis that scores 71 on its first pass does not get its strong sections re-litigated.

3.7 The Thesis gate

When the pipeline reaches its terminal waitpoint, the aggregated thesis is streamed into the artifact pane as a structured, source-linked document — claims, their quotedSpan provenance, confidence, and the honest list of open questions. The user reads it and refines conversationally: go deeper on EU data-residency, the ASO section is thin, treat Android tablet as out of scope. Each refinement re-enters the pipeline as a targeted re-run — new perspectives or reformulated sub-questions — and the thesis live-refactors with a visible diff. Only on explicit approval does the thesis freeze, get committed to the venture's forge repo as a versioned artifact, and become the grounded input to Crucible (§4). The mechanics of that propose→refine→approve loop, its convergence guarantee, and its branded, engine-invisible presentation are the subject of the Refine Loop (§7); here it is enough that the gate is human, versioned, and re-enterable — the research is never done to the user, it is done with them.

---

4. Methodology III — Sovereign White-Label Deploy & Interaction Architecture

The third stage — Crucible — is where a research thesis becomes a running product. It has two faces. The first is infrastructural: Nexus Axiom must stand up a sovereign cell for the venture, a self-contained deployment target the customer wholly owns, that reveals nothing of Adverant at any layer a user or auditor can reach. The second is experiential: the same cell must ship with an interaction surface — full-screen unified chat plus a generative artifact pane — through which every subsequent action is proposed, refined, and governed. This volume treats both. Part A specifies the cell, its isolation contract, and a queueing-grounded model for horizontal scale. Part B specifies the interaction spine: unified chat, AG-UI, the UNO governed-dispatch path, the Progress Command Center, and the inspector's declarative k-cards. Throughout, the Adverant backend is a sealed boundary; we describe contracts and interfaces, never internals.

The organising principle is plugin independence: keep the shared brain, make everything the customer touches sovereign. Concretely, a venture is independent when it satisfies seven criteria — (i) its own source repository, (ii) its own Kubernetes namespace, (iii) its own database with private credentials, (iv) its own OAuth client and identity realm, (v) its own custom domain and TLS, (vi) its own CI/CD pipeline and rollback lineage, and (vii) a federation edge to the shared control plane that is strictly read-only from the venture's side. The seventh criterion is the load-bearing one: the cell may consume the shared cognitive brain (see §2, §8) but never expose venture-side code or customer data back across the edge, and never learn of a sibling tenant's existence.

4.1 The Sovereign Cell

A cell is the unit of tenancy: a Kubernetes namespace plus the durable state and network identity bound to it. The strongest isolation posture in the multi-tenancy literature is the silo model — dedicated resources per tenant — as opposed to a pool (shared resources, logical partitioning) or a bridge (hybrid) [Chong 2006; Kumar 2026]. Nexus Axiom deliberately chooses silo at the layers a customer can observe (compute namespace, database, identity, domain) and accepts pooling only inside the sealed shared brain, which no tenant addresses directly. This mirrors the classical spectrum of tenant-isolation degrees — from shared-everything through shared-nothing — where the correct point on the spectrum is chosen per resource rather than globally [Ochei 2018]. Where two tenants might contend for a shared substrate, performance isolation must be enforced, not merely hoped for: fair-share scheduling and per-tenant rate governance are prerequisites, as Pisces demonstrates for multi-tenant storage [Shue 2012], and as container-level multi-tenant frameworks formalise for the orchestration layer [Zheng 2021]. Network-plane isolation between namespaces is programmable at the flow level in the OpenFlow tradition [Mckeown 2008], which underpins the per-namespace network policies each cell carries.

The customer never sees "Adverant." Brand resolution happens at the edge, during server-side rendering, before the first byte of HTML reaches the browser. The edge worker reads the inbound Host header, looks up the venture's brand descriptor (palette, logotype, copy, legal entity), and renders the shell already themed — so first paint is the venture's brand, with zero Adverant string reachable in markup, headers, or bundle. This is a hard gate in the provisioning sequence below, not a cosmetic afterthought.

Provisioning is deterministic and idempotent. The generated application artifacts are composed from the generalized Pattern Substrate (see §8) — never verbatim proprietary or cross-customer source — behind the IP firewall, then committed to the venture's own repository and rolled out through its own pipeline. Composition of vetted, generalized building blocks (rather than free-form synthesis) is what keeps generated code inside the reliability envelope that current code-generation systems achieve on real repository tasks [Chen 2021; Li 2022; Jimenez 2024].

Plain Text
23 lines
Copy
Algorithm 4.1  ProvisionSovereignCell
Input:  ventureId v; brandSpec b (domain, palette, logo, legalEntity);
        artifacts A (generalized-pattern code-gen output, see §8);
        residencyClass rc (data-residency constraint)
Output: live cell endpoint E, or ABORT with reason

 1  region  <- selectRegion(rc)                 // satisfy data-residency first
 2  ns      <- createNamespace("cell-" + v, region)
 3  applyNetworkPolicy(ns, denyCrossTenant=true) // (i)/(ii) silo compute
 4  repo    <- forge.createRepo(v); seedGitFlow(repo)   // (i) own repo
 5  commit(repo, A)                              // generalized patterns only
 6  db      <- provisionDatabase(ns, isolated=true); runMigrations(db)  // (iii)
 7  oauth   <- registerClient(v, realm="venture-" + v)                  // (iv)
 8  bindDomain(b.domain); tls <- issueCert(b.domain)                    // (v)
 9  configureEdgeSSR(host=b.domain, brand=b)     // brand resolves at edge
10  pipeline<- forgejoCI(repo):                  // (vi) build->scan->sign->ship
        build -> trivyScan -> cosignSign -> pushOCI -> k3sRollout(ns)
11  installHPA(ns, web=[3,15], worker=[2,10], cpu=0.70, mem=0.80)
12  installKEDA(ns, trigger=bullmqDepth, target=T)          // see 4.2
13  fedEdge <- registerFederationEdge(v, mode="read-only") // (vii)
14  assert firstPaintRevealsNoAdverant(b.domain) else ABORT "brand leak"
15  E <- endpoint(b.domain); emitPCC(v, "cell.live", E)
16  return E

Every step is human-gated by the enclosing Refine Loop (see §7): the deploy plan is proposed, the customer reviews the diff and the brand preview, and only an explicit approval advances line 10 onward. Rollback is first-class and cheap — a git revert on the venture repo re-runs the pipeline against the prior tree, so the recovery path is the same code path as a forward deploy, with no bespoke undo machinery.

4.2 Horizontal Scale: A Utilization-Target and Queueing Model

A live venture faces two distinct load shapes, and the cell scales each with a different signal. Synchronous web traffic scales on resource utilization via the Kubernetes Horizontal Pod Autoscaler (HPA); asynchronous work — the BullMQ jobs that UNO enqueues — scales on queue depth via KEDA [Pilyai 2023]. Both are reactive controllers; we combine them with a lightweight proactive envelope in the spirit of hybrid schemes that pair prediction with feedback [Ramperez 2021], and we size the reactive set-points from an offered-load model rather than by guesswork.

HPA set-point. Let $n_{\text{cur}}$ be the current replica count and, for each governed resource $r \in R$ (here CPU and memory), let $u_r$ be the observed mean utilization and $u_r^\star$ the target. The HPA's control law scales each metric proportionally and takes the worst case:

For the web tier we set $u_{\text{cpu}}^\star = 0.70$, $u_{\text{mem}}^\star = 0.80$, and $[n_{\min}, n_{\max}] = [3, 15]$; for the worker tier $[2, 10]$. The targets are utilization headroom choices: a lower $u^\star$ trades cost for burst-absorption capacity, exactly the capacity-versus-responsiveness trade-off that agile provisioning studies characterise for multi-tier applications [Urgaonkar 2008; Gandhi 2012]. Smart-HPA-style resource-efficiency refinements — right-sizing requests so the ratio $u_r/u_r^\star$ is a faithful load signal — apply directly at line 11 of Algorithm 4.1 [Ahmad 2024].

Queue-driven worker scale. The worker tier's true objective is a latency SLO on job completion, so we model it as an $M/M/c$ station and choose $c$ from offered load [Jafarnejad 2019]. Let jobs arrive at rate $\lambda$ (jobs·s⁻¹) and let a single worker serve at rate $\mu$. Define the offered load in Erlangs

with stability requiring $\rho < 1$, i.e. $c > a$. The probability an arriving job must wait is Erlang-C,

and the mean time a job spends queued before a worker frees is

Given a target $W_q^{\text{SLO}}$, the minimal safe worker count is the smallest integer $c^\star$ with $W_q(c^\star) \le W_q^{\text{SLO}}$ and $c^\star > a$. To drive this with KEDA's queue-length trigger — which, like the HPA, scales to $\lceil Q / T \rceil$ replicas for observed queue depth $Q$ and per-replica target $T$ — we choose $T$ so that the controller's equilibrium reproduces $c^\star$. By Little's law the equilibrium queue length at the SLO is $Q^\star = \lambda \, W_q^{\text{SLO}}$, so we set

This closes the loop: the analytic $M/M/c$ solve fixes the target $T$, and KEDA's reactive controller then tracks it against live depth, clamped to the worker bounds $[2,10]$. The set-point $T$ is recomputed as the estimator for $\lambda$ and $\mu$ drifts — a slow proactive outer loop over a fast reactive inner loop, the arrangement FLAS advocates [Ramperez 2021].

TypeScript
15 lines
Copy
// Autoscale contract for a cell (illustrative, interface-level).
interface HpaTarget {
  tier: "web" | "worker";
  minReplicas: number;          // web:3  worker:2
  maxReplicas: number;          // web:15 worker:10
  metrics: Array<{ resource: "cpu" | "memory"; targetUtilization: number }>;
  // desired = clamp(max_r ceil(cur * u_r / uStar_r), min, max)
}

interface KedaQueueTrigger {
  queue: "bullmq";
  correlationScope: string;                 // per-jobType queue
  targetDepthPerReplica: number;            // T = ceil(lambda * WqSLO / cStar)
  // desiredWorkers = clamp(ceil(depth / targetDepthPerReplica), 2, 10)
}

The multi-tenancy guarantee survives scaling because each cell autoscales within its own namespace against its own metrics; a noisy neighbour cannot exist when there is no neighbour to be noisy, and the shared brain the cell reads is rate-governed at the federation edge [Shue 2012; Kumar 2026].

4.3 Code-Generation from the Pattern Substrate

The artifacts A in Algorithm 4.1 are not written from a blank page. They are composed from generalized, interface-level patterns indexed by the Pattern Learning Substrate (see §8) — architecture skeletons, data-model shapes, wiring conventions distilled from prior Adverant platforms and stripped of any proprietary or cross-customer specifics behind the IP firewall. Composition from a curated library, then machine verification, is what current evidence supports as the reliable regime for code generation, versus unconstrained synthesis [Chen 2021; Li 2022; Jimenez 2024]. The verification is the Forgejo pipeline itself: build → trivy → cosign → OCI → k3s. A build that fails compilation, a Trivy scan that surfaces a critical CVE, or an unsigned image never reaches rollout — the pipeline is the acceptance test, and its green state is the precondition the Refine Loop presents to the human approver.

4.4 The Interaction Surface

A deployed cell is inert without a way to act on it. Nexus Axiom's answer is a single, consistent interaction surface that is the product chrome for every venture: a full-screen unified chat paired with a generative artifact pane. This is not a chat widget bolted onto pages. It is the primary surface; conventional forms and dashboards are things the agent renders into the pane when they are the right tool, not the default scaffolding.

The surface model. One UnifiedChatPanel is mounted per route tree and auto-attaches CMA memory through ChatSurfaceShell (see §2 for the memory architecture). Its shape is a small product of orthogonal axes: a channel kind (talking to the assistant vs. a comms channel), a panel mode (conversational vs. terminal), and a dock position. Encoding these as an explicit model — rather than as ad-hoc component state — is what lets the same panel be a floating helper on one route and a full-bleed terminal on another without divergent code paths.

TypeScript
13 lines
Copy
// Unified-chat surface model (illustrative, interface-level).
type ChannelKind  = "assistant" | "comms";
type PanelMode    = "chat" | "terminal";
type DockPosition = "float" | "right" | "bottom" | "popout" | "minimized";

interface UnifiedChatSurface {
  channel: ChannelKind;
  mode: PanelMode;
  dock: DockPosition;
  sessionId: string;                 // carried on every dispatch
  transport: "socket.io" | "sse";    // SSE fallback after 3 failed sockets
  memoryAttached: boolean;           // CMA via ChatSurfaceShell
}

Streaming is Socket.IO first, degrading to Server-Sent Events after three consecutive socket failures — a resilience contract, not a feature toggle, so a hostile network never leaves a venture's operator staring at a frozen surface.

The artifact pane and AG-UI. The pane (ArtifactPanel with pluggable renderers, arranged by ArtifactSplitLayout) is where the agent streams dynamic, MCP-tool-driven UI components — the AG-UI pattern. Rather than the model returning prose that a human must act on, the agent emits typed UI events that renderers turn into live, interactive components in the pane. This is the natural endpoint of the tool-use and generative-UI line of work: models that decide when and which tool to invoke [Schick 2023; Yao 2023], that select correctly from large, real API surfaces [Patil 2023; Qin 2024], that operate a computer/agent interface to accomplish engineering tasks [Yang 2024], and that map an intended design to a working front-end [Si 2024]. AG-UI is that literature made operational: the "tool" the agent calls is a UI component, and its "output" is something the user can see and manipulate.

Governed dispatch. Crucially, no rendered control acts on its own authority. Every action — whether a button in a k-card, a form the agent rendered, or a chat instruction — funnels through the Unified Nexus Orchestrator (UNO): a single entrypoint POST /api/v1/dispatch that resolves the requested skill, runs a five-gate pre-execution broker, and only then enqueues work for nexus-workflows, the sole executor. The gates are ordered and total: classification → data-residency → export-class → spend → safety. Any gate may deny, and denial is legible (it carries a reason the surface can display). This is the governed spine that makes the generative UI safe: the agent may propose any action by rendering a control, but the control's effect is mediated by a broker the agent does not control.

TypeScript
20 lines
Copy
// UNO dispatch contract (illustrative; validated server-side).
interface DispatchRequest {
  jobType: string;            // resolves to a registered skill
  organizationId: string;     // tenant scope (the cell)
  userId: string;
  inputParams: Record<string, unknown>;
  appId: string;
  pluginId: string;
  sessionId: string;          // ties to the UnifiedChatSurface
  correlationId: string;      // BullMQ key; mirrored into PCC + AG-UI stream
}

interface DispatchResult {
  jobId: string;
  correlationId: string;
  status: "accepted" | "denied";
  deniedGate?: "classification" | "data-residency"
             | "export-class" | "spend" | "safety";
  reason?: string;            // human-legible when denied
}

Plain Text
15 lines
Copy
Algorithm 4.2  GatedDispatch  (POST /api/v1/dispatch)
Input:  DispatchRequest d
Output: DispatchResult

 1  authorize(d.organizationId, d.userId, d.appId)   // tenant-scoped
 2  skill <- resolveSkill(d.jobType); if !skill: return denied("classification")
 3  for gate in [classification, dataResidency, exportClass, spend, safety]:
 4      verdict <- gate.evaluate(d, skill)
 5      if verdict = DENY:
 6          emitPCC(d.correlationId, "dispatch.denied", gate.name)
 7          return { status:"denied", deniedGate: gate.name, reason: verdict.why }
 8  job <- bullmq.enqueue(d.jobType, d, key = d.correlationId)   // workflows only
 9  emitPCC(d.correlationId, "dispatch.accepted", job.id)
10  // nexus-workflows dequeues, executes, streams AG-UI events + PCC progress
11  return { jobId: job.id, correlationId: d.correlationId, status:"accepted" }

The gate order is not arbitrary. Classification determines what kind of thing is being asked and is therefore prerequisite to every downstream check; data-residency and export-class enforce the sovereignty guarantees of §4.1 before any compute is committed; spend caps cost before work is enqueued, not after it has run; safety is last so it can see the fully resolved request. Because the executor is singular (nexus-workflows) and the entrypoint is singular (/api/v1/dispatch), there is exactly one place where governance lives — no side door, no privileged client that skips the broker.

4.5 Progress, Inspection, and Declarative K-Cards

Two supporting surfaces complete the architecture. The Progress Command Center (PCC) is a persistent, cross-plugin dock that mirrors UNO runs over WebSocket: because every dispatch carries a correlationId (Algorithm 4.2, lines 6–9), the PCC can render a live, unified view of everything in flight across a venture, regardless of which plugin or route originated it. Progress is never inferred from the client; it is streamed from the executor keyed on the same correlation id that names the BullMQ job.

The inspector is a right-docked pane bound to the current selection, and it is populated declaratively. Rather than hand-coding an inspector per entity type, the agent emits a small grammar of k-cards — KbCardDef values — that renderKbCard turns into ros atoms. The card kinds are deliberately few (kv, metric, section, action, link, bar, props), which keeps the grammar auditable and the rendering total. Two rules make the inspector trustworthy. First, an action card does not act locally — it dispatches through UNO, so it inherits the full five-gate governance of §4.4. Second, a missing value renders as an em-dash —; it is never fabricated, so the absence of data is visible as absence rather than papered over with a plausible-looking default.

TypeScript
24 lines
Copy
// Declarative inspector grammar (illustrative, interface-level).
type KbCardDef =
  | { kind: "kv";      label: string; value: string | number | null }
  | { kind: "metric";  label: string; value: number | null; unit?: string }
  | { kind: "section"; title: string; cards: KbCardDef[] }
  | { kind: "action";  label: string; dispatch: Partial<DispatchRequest> }
  | { kind: "link";    label: string; href: string }
  | { kind: "bar";     label: string; value: number | null; max: number }
  | { kind: "props";   entries: Array<{ k: string; v: string | null }> };

function renderKbCard(def: KbCardDef): RosAtom {
  switch (def.kind) {
    case "kv":
    case "metric":
      // missing value -> "—", never invented
      return atom(def.label, def.value ?? "—");
    case "action":
      // action fires through UNO -> five-gate broker -> workflows
      return actionAtom(def.label, () => dispatch(def.dispatch));
    // ...remaining kinds omitted for brevity
    default:
      return atom("", "—");
  }
}

Together these surfaces realise a single claim: the customer's product is a governed conversation with a generative interface. The chat proposes; the artifact pane renders; the inspector exposes state without inventing it; the PCC narrates progress; and UNO's five gates stand between every proposed action and its execution. That governed-proposal shape is exactly what the Refine Loop (see §7) makes invisible — the human sees a coherent product, while every consequential step is a propose → refine → approve cycle whose approval is an ordinary dispatch through the same spine. The Crucible thus hands the Apex stage (see §5) a cell that is sovereign at every observable layer, horizontally elastic against a modelled load, and instrumented so that the live product and its human operator share one honest picture of what the system is doing.

---

5. Methodology IV — Live Gated Product & Versioned Re-entry

The venture is live. A user reached this point through Catalyst, Thesis, and Crucible (see §2, Ideation; §3, Research; §4, Deploy); the product now runs inside its own sovereign cell — a dedicated Kubernetes namespace, edge-SSR brand resolution that reveals nothing of Adverant at first paint, its own repository on forge.adverant.ai, its own database and OAuth. This is the Apex stage. But "live" is not a terminal state, and it is not the end of the pipeline. It is the point at which the pipeline closes into a loop.

Two claims organize this volume. First, the Apex operating model: a live, self-healing, white-labelled product in which every autonomous action — including the system's own remediations — remains human-gated through the invisible Refine Loop (see §7). Second, versioned re-entry: venture state is a versioned artifact graph, so that a pivot — even one that edits an already-deployed site — is not a rebuild but a diffable, revertible commit that re-enters the gated pipeline exactly where it must, and nowhere else.

5.1 The Apex operating model

A live cell is not static. Load fluctuates; dependencies drift; error budgets erode. Two reactive controllers already run beneath the surface (see §4, Deploy): the HPA scales web pods 3→15 against CPU (70%) and memory (80%) thresholds [Ahmad 2024], and KEDA scales worker pods 2→10 on BullMQ queue depth [Pilyai 2023], following a standard queueing model [Gandhi 2012; Jafarnejad 2019]. These keep the product responsive. They do not keep it correct.

Correctness — and the graceful degradation we call self-healing — is the province of nexus-alive, described here strictly at its interface. Alive is a monitoring agent, not a black box of imperatives. It observes the cell's service-level objectives, watches the error budget, and detects anomalies; when it finds a fault it does not silently mutate production. It emits a proposal. That proposal enters the same Refine Loop that gated every prior stage, and it routes any corrective action back through UNO's single dispatch entrypoint (POST /api/v1/dispatch, see §4, Deploy), so that the five-gate broker — classification, data-residency, export-class, spend, safety — adjudicates a self-healing action with exactly the discipline it applies to a human-initiated one.

Autonomy is tiered, and the tier is a function of blast radius. A reversible, low-radius remediation — restarting a wedged worker, widening a connection pool, rotating a cache — may execute automatically and report after the fact. An irreversible or high-radius one — a schema migration, a config change touching billing, a rollout that cannot be trivially undone — is gated: it waits for a human. This is mixed-initiative interaction in its original sense [Horvitz 1999]: the machine takes initiative where its confidence and the expected cost of error warrant it, and defers where the stakes exceed that budget. The four interface obligations follow Amershi's guidelines [Amershi 2019] — make plain what the agent can do, surface the contextually relevant signal, support efficient correction, and convey the consequence of each choice before it is taken.

TypeScript
9 lines
Copy
// nexus-alive emits proposals; it does not act unilaterally on high-radius faults.
interface RemediationProposal {
  ventureId: string;
  signal: 'slo-breach' | 'error-budget' | 'anomaly' | 'saturation';
  blastRadius: 'reversible' | 'irreversible';
  action: DispatchRequest;      // routed through UNO's 5-gate broker (see §4, Deploy)
  autonomy: 'auto' | 'gated';   // 'gated' iff irreversible OR high-radius
  rationale: string;            // shown in the PCC before any human decision
}

The proposer that composes a RemediationProposal is itself a reflective agent loop of the kind now standard in the literature: verbal self-critique over prior attempts [Shinn 2023], multi-agent conversation among specialized roles [Wu 2023], and role-structured decomposition of the diagnosis [Hong 2024]. Where the venture warrants it, Alive can drive a simulated user against a canary to probe a change before it touches real traffic [Park 2023]. None of this reflection reaches production on its own authority. Every Alive run mirrors into the Progress Command Center over WebSocket, so the operator watches the live product's autonomic activity in the same persistent dock that mirrored the build. The inner loop is agentic; the outer loop is human. Agents propose; humans dispose.

5.2 Venture state as a versioned artifact graph

To make re-entry precise, we need a formal object for "the venture." A live product is not a single file and not a single deploy — it is a coherent set of derived artifacts: the ideation hypothesis, the thesis dossier, the brand tokens, the deploy manifest, the generated code modules, the live configuration. Each was produced by an owning stage, and each depends on those upstream of it.

Model this as a directed acyclic graph $G = (A, D)$, where $A$ is the set of artifacts and an edge $(d, a) \in D$ means $a$ was derived from $d$. Assign each artifact a content hash $h : A \to \{0,1\}^{256}$ over its canonical serialization. A version $v$ is an immutable snapshot of $G$, identified by a Merkle-style root over the artifacts reachable within it,

so that two versions are content-identical iff $H(v) = H(v')$. The versions themselves form a second DAG — a history $\mathcal{V}$ with parent edges for commits, branches, and merges. This is not a metaphor for git; it is git, made semantic: every version maps to a commit on the venture's forge repository, and every live version maps to a tag.

Now the central operation. A pivot is an edit $\Delta \subseteq A$ — the user changes a hypothesis, swaps a brand palette, rewrites a page, adjusts a pricing rule. Let $\rightsquigarrow$ denote reachability along derivation edges $D$. The edit invalidates exactly the transitive dependents of $\Delta$ together with $\Delta$ itself — the stale cone of influence:

Everything outside $C(\Delta)$ is provably unaffected and is carried forward untouched. This is what makes re-entry incremental rather than total: a change to a brand token re-derives the surface that renders it, not the market thesis that preceded it; a change to the hypothesis re-derives nearly everything downstream, and correctly so.

TypeScript
35 lines
Copy
type Stage = 'catalyst' | 'thesis' | 'crucible' | 'apex';
type ArtifactKind =
  | 'hypothesis' | 'thesis-dossier' | 'brand-tokens'
  | 'deploy-manifest' | 'code-module' | 'live-config';

interface ArtifactRef {
  id: string;
  kind: ArtifactKind;
  contentHash: string;      // h(a): sha256 of canonical serialization
  producedBy: Stage;        // owning engine that can re-derive it
  derivedFrom: string[];    // parent artifact ids — the edges of D
}

interface GateApproval {
  stage: Stage;
  approvedBy: string;       // userId — the human is the final authority
  refineIterations: number; // propose->refine->approve rounds (see §7)
  approvedAt: string;       // ISO 8601
}

interface PlanVersion {                 // the venture-state record
  ventureId: string;
  versionId: string;        // 1:1 with a forge git tag when live
  parentVersionId: string | null;       // the parent in history DAG V
  branch: string;           // GitFlow branch on forge.adverant.ai
  commitSha: string;
  entryStage: Stage;        // where this re-entry began
  artifacts: ArtifactRef[]; // the snapshot of G at this version
  merkleRoot: string;       // H(v)
  staleFrom: string[];      // artifact ids in C(Δ), re-derived this pass
  gates: GateApproval[];    // one per re-derived, human-approved stage
  deployTag: string | null; // set on cutover; null while a candidate
  status: 'candidate' | 'gated' | 'live' | 'reverted';
  createdAt: string;
}

5.3 The re-entry / versioned-pivot loop

Re-entry follows a single procedure. The user names what they want to change and, implicitly, the stage it belongs to; the system computes the smallest correct set of work, re-derives it through the same gated engines, presents a diff, and — only on approval — cuts it over.

Plain Text
25 lines
Copy
Algorithm: Versioned Re-entry & Pivot  (Apex loop)
Input:  v_live  — the live venture version (graph G, deploy tag τ_live)
        ε = (Δ, s) — edit intent: artifacts Δ, target stage s
Output: a new live version v', or ⊥ (discarded; live state untouched)

 1.  branch  ← fork forge repo from tag τ_live         // GitFlow feature branch
 2.  C       ← Δ ∪ { a ∈ A : ∃ d ∈ Δ, d ⇝ a }          // stale cone of influence
 3.  order   ← topologicalSort(C, D)                    // respect derivation order
 4.  for each artifact a in order do
 5.      e   ← owningEngine(a)                          // Catalyst / Thesis / Crucible
 6.      a'  ← RefineLoop(e, a, context(a))             // propose→refine→approve (§7)
 7.      if a' rejected by human then
 8.          discard branch; return ⊥                   // human is final authority
 9.      commit a' to branch;  h(a') ← hash(a')
10.  v_cand ← snapshot(G');  v_cand.merkleRoot ← H(v_cand)
11.  diff   ← G' ⊖ G                                    // artifact-level diff vs live
12.  d      ← humanGate(diff)                           // mixed-initiative review
13.  if d = approve then
14.      τ'  ← tag(commit)
15.      CI: build → trivy → cosign → OCI registry → k3s rollout
16.      edgeResolver.cutover(venture, τ')              // zero-reveal SSR (see §4)
17.      v'.status ← 'live';  v'.deployTag ← τ'
18.      return v'
19.  else if d = refine then  goto 4 with revised ε     // outer refine iteration
20.  else  discard branch; return ⊥                     // τ_live never mutated

Three properties are worth naming. The branch is cut from τ_live and the live tag is never mutated until line 16, so a candidate that fails review costs nothing and changes nothing. Each re-derivation in line 6 is wrapped in the Refine Loop — the same invisible propose→refine→approve contraction whose convergence is established in §7 (the Refine Loop) — so the human gate is not a single checkpoint bolted onto the end but a property of every artifact along the topological order. And the diff at line 11 is computed over artifacts, not text: the operator sees the thesis changed, the pricing page changed, the market analysis did not, which is the granularity at which a founder actually reasons about a pivot.

Human-in-the-loop software agents that surface intermediate artifacts for correction converge faster and are trusted more than end-to-end black boxes [Takerngsaksiri 2024]; the collaborative-planning literature makes the same point for multi-agent systems, where steering the plan mid-flight — not just accepting or rejecting the result — is what keeps a human in genuine control [He 2026]. Trust in an LLM planner is contingent, provisional, and easily lost [Chen 2025]; the artifact-level diff and the per-stage gate are how Apex earns it on every pivot rather than assuming it once.

5.4 Revertibility, branching, and blast-radius containment

Because every live version is a tag and every deploy is tied to that tag, rollback is not a special subsystem — it is git revert. Let $L \in \mathcal{V}$ be the pointer to the currently live version. A rollback is

followed by a redeploy of $v_{\text{prev}}$'s image, which the registry already holds, signed, from its original build. No re-derivation, no rebuild. The failure is contained to the cell — the sovereign namespace, the sovereign database — so a bad pivot in one venture cannot reach another. This is the plugin-independence thesis paying a dividend at runtime: isolation that was a deployment property becomes a recovery property.

The version DAG also admits branching in the forward direction. A founder unsure between two directions can carry two candidate versions, $v_a$ and $v_b$, sharing a parent; the edge resolver can route a fraction of traffic to a canary tag before cutover, and Alive can watch both under the tiered-autonomy rules of §5.1. The pipeline being a loop rather than a line is precisely what makes this cheap: the same machinery that re-enters for a single change re-enters for an experiment, because both are just new versions in $\mathcal{V}$.

5.5 The human as final authority, at every altitude

Nothing in the Apex stage removes the human. The reactive controllers keep the product responsive; Alive keeps it correct; the reflective inner loops keep the proposals good. But the outer loop — every irreversible remediation, every pivot, every cutover — resolves through the Refine Loop to a person who approves, refines, or rejects. The design is deliberately conservative about where autonomy is granted, and deliberately transparent about it, because the evidence is that trust in autonomous planners is fragile and consequence-sensitive [Chen 2025; Horvitz 1999]. A venture that can pivot itself into ruin unattended is not sovereign; it is merely unsupervised. Apex is the stage where the loop closes — and the human is the one who decides, each time, whether it closes again.

---

6. Research-Grounded Design Psychology & UI/UX System

A venture builder that asks a non-technical founder to hand over an idea and then approve irreversible actions (see §7) lives or dies on a variable most engineering teams treat as garnish: whether the surface looks like it can be trusted. This is not a matter of taste. In the largest study of its kind — 2,684 people judging live sites — the single most frequently cited determinant of credibility was the "design look" of the interface, present in 46.1% of participants' comments, ahead of information structure and focus [Fogg 2003]. Prominence-interpretation is the mechanism: users notice the visual layer first, and interpret everything else through it. For Nexus Axiom, where every gate is a moment of consequence, the design system is therefore a load-bearing component of the safety story, not an aesthetic afterthought.

We consequently derive the design system from evidence rather than choosing it, and we reject two attractors by name and with reasons: dark-by-default and the generic "AI" aesthetic. Both are argued below from the literature, not asserted. Throughout, we tune to internal, generalized personas — trait distributions, never named individuals or inferred private attributes (the psychometric wall). The output is a token contract, a palette-derivation algorithm, and an interaction specification for the surfaces §4 and §7 already defined.

6.1 Design as a Credibility and Conversion Instrument

Two robust findings anchor the whole system. First, credibility is read primarily off the visual layer [Fogg 2003]. Second, the aesthetic-usability effect: perceived beauty raises perceived usability and, critically, users' tolerance for friction — Tractinsky's ATM experiment showed that manipulated aesthetics moved post-use perceptions of usability even when actual usability was held constant [Tractinsky 2000]. The practical corollary for a propose→refine→approve product is precise: a plan that looks considered is read as being considered, so the design system's first job is to make the machine's proposals legible and trustworthy at a glance, before a single word is parsed. Design is thus upstream of conversion, and conversion here means "the founder is willing to approve."

6.2 Personas as Generalized Psychographic Axes

Aesthetic preference is not uniform, and it is not random — it covaries with personality and demographics in measurable ways. Openness to Experience is the strongest personality predictor of aesthetic engagement and preference (as distinct from judgment ability, which tracks intelligence) [Afhami 2018], and large-scale work quantifies how preferences for visual complexity and colourfulness shift systematically across populations [Reinecke 2014]. We turn this into an internal, generalized model: a persona is a Big-Five trait vector plus derived aesthetic parameters, never a real person and never a sensitive inference (psychometric wall).

TypeScript
23 lines
Copy
// Generalized persona model — internal only; no real individuals, no PII.
interface PersonaProfile {
  // Big-Five, standardized [-1, 1]; population aggregates, not individuals.
  openness: number; conscientiousness: number; extraversion: number;
  agreeableness: number; neuroticism: number;
}

interface AestheticParams {
  complexity: number;    // 0 = spare … 1 = dense  (Reinecke 2014 preference axis)
  colorfulness: number;  // 0 = restrained … 1 = vivid
  expressive: number;    // 0 = classical … 1 = expressive (Afhami 2018 axis)
}

// Trait → aesthetic mapping. Openness raises tolerance for complexity/expression;
// conscientiousness and neuroticism pull toward classical, low-complexity, legible.
function personaToAesthetic(p: PersonaProfile): AestheticParams {
  const clamp01 = (x: number) => Math.min(1, Math.max(0, x));
  return {
    complexity:   clamp01(0.35 + 0.30 * p.openness - 0.20 * p.conscientiousness),
    colorfulness: clamp01(0.30 + 0.25 * p.openness - 0.15 * p.neuroticism),
    expressive:   clamp01(0.30 + 0.40 * p.openness),
  };
}

Because Nexus Axiom serves many venture types at once, the system's default is the robust centre — the moderate-complexity, moderate-colourfulness region that is broadly preferred across the widest population [Reinecke 2014] — and it lets per-venture brand resolution at the edge (see §4) tune within evidence-bounded rails rather than off a designer's whim. A high-Openness founder building an art marketplace and a high-Conscientiousness operator building a compliance tool receive the same governed surface with different aesthetic parameters, both provably accessible.

6.3 The Palette: Derived from Colour Psychology, Constrained by Accessibility

Colour is the most-loaded and most-abused lever, so we derive it rather than pick it. The empirical backbone is the Pleasure–Arousal–Dominance (PAD) model of colour affect, whose standardized regressions on brightness $B$ and saturation $S$ are [Valdez 1994]:

Read these as a design brief. Pleasure rises with brightness; arousal is driven by saturation and damped by brightness; dominance falls with brightness. A high-stakes approval surface wants high pleasure and low arousal (calm, not agitated) and low dominance (collaborative, not domineering). The objective is therefore a constrained optimum — maximise pleasure subject to an arousal budget $a_{\max}$:

Since pleasure increases in both variables while arousal is the binding constraint, the solution pushes brightness high and holds saturation low-to-moderate — i.e. a light, restrained palette, not a dark, vivid one. Hue then carries meaning: across studies the blue–green family is the most consistently pleasant and is culturally coded toward competence and trust, while high-saturation yellow-greens are least pleasant [Valdez 1994; Elliot 2014]. Nexus Axiom's default therefore anchors its primary in blue, reserves a single warm accent for action affordances (drawing the eye precisely where a consequential click lives), and keeps everything else quiet.

Colour associations are not universal law — Elliot & Maier caution that effects are context-dependent and moderated by culture and task [Elliot 2014] — which is exactly why hue is a brand-tunable parameter while the structure (light base, low arousal, warm-accented action) is fixed by the objective above.

Accessibility is a hard floor, not a preference. WCAG 2.1 requires a contrast ratio of at least 4.5:1 for body text (3:1 for large text and graphical objects) [WCAG 2.1], computed from relative luminances $L_{\text{light}} \ge L_{\text{dark}}$ as

Every derived token must clear this before it ships. The palette is thus the output of an algorithm, not a mood board:

Plain Text
17 lines
Copy
Algorithm 6.1  DeriveAccessiblePalette
Input:  brand hue h_b (deg); arousal budget a_max; aesthetic params ap (§6.2)
Output: token set K passing WCAG 2.1 AA, or FALLBACK to canonical light theme

 1  B, S <- argmax pleasure s.t. arousal(B,S) <= a_max          // §6.3 objective
 2  surface <- color(hue=neutral, brightness=high(B))           // light base
 3  text    <- darkest neutral s.t. CR(text, surface) >= 7.0    // AAA where cheap
 4  primary <- color(hue = h_b OR blueDefault, sat = clamp(S, ap.colorfulness))
 5  onPrimary <- pick({white, text}) maximizing CR(·, primary)
 6  while CR(onPrimary, primary) < 4.5:  primary <- darken(primary)   // clamp to AA
 7  accent  <- warmComplement(primary, sat = clamp(S, ap.colorfulness))
 8  // diff + status semantics: never color alone (WCAG 1.4.1) — pair with icon+label
 9  add    <- {hue: green,  CR>=3:1, icon: "+", label: "added"}
10  remove <- {hue: rose,   CR>=3:1, icon: "−", label: "removed"}
11  modify <- {hue: amber,  CR>=3:1, icon: "~", label: "changed"}
12  assert all(CR(t, surface) >= floor(t) for t in K) else return FALLBACK
13  return K

6.3.1 Why Not Dark-by-Default — the Evidence

The generic "AI product" ships dark-first. We refuse it as the default for three grounded reasons, not one aesthetic preference. (1) Reading performance. The positive-polarity advantage is well established: dark text on a light background yields faster, more accurate proofreading and better acuity than light-on-dark, an effect that strengthens at small character sizes because a brighter field contracts the pupil and sharpens the retinal image [Piepenbrock 2014]. The core act of the Refine Loop is reading a proposed plan and its diff and deciding (see §7); reading performance is therefore a conversion metric, and we optimise for it. (2) Credibility. Since credibility is read off the visual layer [Fogg 2003] and the aesthetic-usability effect rewards perceived polish [Tractinsky 2000], the default should sit in the broadly-preferred, high-brightness region [Reinecke 2014] rather than a niche that reads as "developer tool." (3) Breadth. A light, moderate-colourfulness base is the widest-preference centre across populations [Reinecke 2014].

Dark mode is not banned — it is demoted to an explicit, user-selected accommodation (OLED battery, low-light, personal preference), fully themed and equally accessible, respecting the OS prefers-color-scheme signal when the user has expressed it. Default light, honour the opt-out; the opposite of the AI-slop convention, and defensible line by line.

6.4 Typography and Layout: Engineering for Low Cognitive Load

Working memory is the scarce resource. Miller's classic bound — roughly seven ($\pm 2$) chunks held at once [Miller 1956] — and cognitive-load theory's distinction between intrinsic, extraneous, and germane load [Sweller 1988] jointly prescribe the layout: chunk information, eliminate extraneous ornament, and stage complexity through progressive disclosure so the founder is never shown more than the decision at hand requires. This is Nielsen's "aesthetic and minimalist design," "recognition rather than recall," and "visibility of system status" made concrete [Nielsen 1994] — the last mapping directly onto the Progress Command Center (see §4), which keeps the system's state continuously visible so the user never has to remember what is running.

The typographic system follows from legibility, not fashion: a single humanist sans for UI with a modest modular scale (ratio $\approx 1.25$), a measure held near 60–75 characters for sustained reading of proposals, generous line-height ($\approx 1.5$) on body copy, and a spacing rhythm on a 4px base so vertical grouping does the chunking Miller demands. Emphasis is carried by weight and size, not colour, so meaning survives colour-vision deficiency and greyscale.

TypeScript
13 lines
Copy
// Design-token contract (illustrative, interface-level). Every value is either
// derived (Algorithm 6.1) or fixed by a cited constraint; none is arbitrary.
interface DesignTokens {
  color: {
    surface: string; text: string;         // CR(text,surface) >= 7  (§6.3)
    primary: string; onPrimary: string;    // CR >= 4.5              (§6.3)
    accent: string;                        // action affordances only
    diff: { add: string; remove: string; modify: string }; // + icon+label
  };
  type: { base: number; scale: number; measureCh: number; lineHeight: number };
  space: { base: number };                 // 4px rhythm -> Miller chunking
  motion: { durationMs: number; easing: string; reducedMotion: boolean };
}

6.5 Motion: Narration, Not Decoration

Motion in Nexus Axiom is functional and it earns its place by narrating a state change the user must understand. The canonical case is the Refine Loop's visible diff (see §7): when the founder says "drop the loyalty feature," the plan live-refactors and steps animate — added, removed, reordered — over the prior revision, so the user literally watches their words become structure. This is visibility-of-system-status [Nielsen 1994] expressed in time. Everything decorative is cut. Durations are short (120–240 ms), easing is standard, and — as an accessibility invariant, not a nicety — prefers-reduced-motion collapses transitions to instantaneous state swaps. Motion that does not disambiguate a state change does not exist in the system.

6.6 Frictionless UX and the Interaction Model

The surfaces are already specified — full-screen unified chat plus the AG-UI artifact pane, all consequential actions routed through UNO's five-gate broker (see §4). The design system's contribution is to make that spine frictionless and legible, governed by four principles drawn from human-AI interaction research and operationalized here:

• Progressive disclosure / low cognitive load [Miller 1956; Sweller 1988]. The founder sees a conversation and, when relevant, one artifact; the machinery of planning, dispatch, and gating is hidden until inspection is requested. This is also the aesthetic case against clutter [Nielsen 1994].
• Omnipresent, single-surface chat. One consistent affordance across every route removes the mode-switching cost; recognition replaces recall because the way to ask for anything is always the same place [Nielsen 1994].
• Make capability and state legible [Amershi 2019]. Guidelines G1–G2 (make clear what the system can do and how well) map to the artifact pane's rendered proposals and to confidence cues on the diff; "support efficient correction and dismissal" (G9) maps to the Refine Loop's edit-in-place; "scope services when in doubt" maps to the five gates that deny legibly, with a human-readable reason (see §4).
• Mixed-initiative, human-ratified [Horvitz 1999]. The system acts on uncertainty by proposing, never by presuming; the human holds the only edge into side effects (see §7).

The proposed-plan + diff surface deserves a concrete design spec because it is where trust is won or lost. It is a light card in the artifact pane, body text at AAA contrast for effortless reading, with change semantics encoded redundantly: colour and a glyph (+ / − / ~) and a text label — never colour alone, satisfying WCAG's use-of-colour criterion so a red-green-deficient founder loses no information [WCAG 2.1]. A per-refinement confidence/gapDelta cue (defined in §7) is rendered as a small directional indicator, giving the "how well does the system perform" signal that Amershi's guidelines call for [Amershi 2019] without ever letting a UI hint act as a gate.

6.7 Rejecting the Generic "AI" Aesthetic

There is now a recognizable template — dark canvas, neon-on-black gradients, a default indigo/purple, glassmorphism, restless ambient motion — that signals "an AI made this." We reject it on principle and on evidence. First, it is a prototypicality-without-distinctiveness signal: it makes a product look like every other AI demo, which is corrosive precisely for Nexus Axiom, whose entire thesis is a sovereign, customer-owned, white-label product that must present the venture's brand and reveal nothing of the builder beneath it (see §4). A generated surface that screams "AI template" defeats sovereignty as surely as an Adverant string in the markup. Second, its dark-first default fails the reading-performance and credibility evidence of §6.3. Third, generative front-end capability has matured to where bespoke, brand-faithful interfaces are automatable [Si 2024]; there is no efficiency excuse for defaulting to a generic skin. The Nexus Axiom system instead derives each venture's surface from Algorithm 6.1, anchored on the venture's own brand hue and tuned by its personas — so no two ventures look "like an AI made them," and each one clears the same accessibility floor.

The synthesis, then, is a design system that is earned at every layer: a light, blue-anchored, low-arousal palette optimised against a cited colour-affect objective and clamped to WCAG AA; a typographic and spatial rhythm engineered against working-memory limits; motion that narrates rather than decorates; and an interaction model that keeps the human in ratifying control of a legible, governed conversation. It is the visual and experiential complement to the Refine Loop's safety guarantee — the machine proposes in a surface built to be read and believed, and the human, seeing clearly, decides.

---

7. The Refine Loop (Flagship)

Every stage of Nexus Axiom is a gate, and every gate is the same loop. The system proposes. The user refines. The system converges. Only then does anything execute. This is the Refine Loop — the propose→refine→approve cycle that wraps Catalyst, Thesis, Crucible, and Apex alike (see §2–§5), and that re-arms on every re-entry and versioned pivot (see §5). It is the paper's flagship contribution not because it is elaborate — it is deliberately plain — but because it is the single mechanism that makes an AI-orchestrated venture builder safe to hand a human idea. Nothing irreversible happens without an approval. Nothing reaches an approval without first being made legible.

The user never sees the engine. There is no "planner," no "agent graph," no toolchain vocabulary on screen. What the user sees is a proposed blueprint in the artifact pane and one branded affordance: Review & Refine. Behind that affordance is agentic planning; in front of it is a document you can argue with. This is the generalization of Claude-Code-style plan mode — where a coding agent drafts a plan and waits for a go — lifted out of the developer terminal and turned into a product surface for a non-technical founder, with the mechanism hidden and the ergonomics made conversational.

7.1 What the loop does, at the surface

The loop has exactly three moves, and the user is the initiative-holder at each turn — a mixed-initiative interface in the sense of Horvitz [Horvitz 1999], obeying the interaction guidelines of Amershi et al. [Amershi 2019]: the system makes clear what it heard, shows what it will do, and never acts without consent.

1. Propose. The system renders a ProposedPlan into the artifact pane (the AG-UI surface, see §4): an intent digest (its own paraphrase of what it heard), a list of concrete steps, and a plain-language rationale. Each step is, internally, a would-be UNO dispatch (see §4) — but it is drawn, not fired.
2. Refine. The user replies in natural language through the unified chat panel: "make it Irish-market first," "drop the loyalty feature," "cheaper hosting." The plan live-refactors in place. A visible diff — steps added, removed, modified, reordered — animates over the prior revision, so the user watches their words become structure (the diff is styled per the not-dark, evidence-derived design system, see §6).
3. Approve. Only on an explicit approval does the plan cross from artifact into action: each approved step is dispatched to UNO's single entrypoint (POST /api/v1/dispatch), passes the five-gate broker, and enters execution (see §4). Approval is the only edge into side effects.

That third property is the whole safety story. Propose and Refine are pure with respect to the outside world; they touch no customer data, spend no budget, provision no cell. The engine may think as hard as it likes — research and ideation are pinned to frontier models at maximum thinking (see §2) — but its output is inert until a human says yes.

7.2 A formal model: refinement as a contraction

We now give the loop a mathematical spine. The claim is modest and precise: under stated assumptions, the number of refine rounds needed to reach an approvable plan is small and bounded, decaying geometrically in the residual mismatch between plan and intent. The human approval remains the ground-truth termination condition; the model explains why approval tends to arrive after a handful of rounds rather than an unbounded argument.

Setup. Let $(\mathcal{P}, d)$ be the space of plans — structured blueprints — equipped with a complete metric $d$. Let the user hold a latent intent $u^\star \in \mathcal{I}$, unobserved and, in general, itself sharpened during the dialogue. Define an intent-gap functional

A user issues feedback $f_k$ at round $k$; the system applies a refinement operator $T$ to produce the next plan,

where $s$ is the stage's intent seed. Model competent feedback as a function of the current gap — the user critiques exactly what is wrong, $f_k = \phi(p_k, u^\star)$ — and fold it into a single self-map on plans (for a momentarily fixed intent):

A fixed point $p^\star = S(p^\star)$ is a plan the user no longer critiques: refinement returns it unchanged. That is precisely the plan that gets approved. This is the same conceptual object as a deep-equilibrium layer, where the output is the fixed point of a stable operator rather than the last item of a fixed unrolling [Bai 2019], and it mirrors equilibrium-sequence formulations of long-horizon planning [Li 2025].

Assumptions.

• (A1) Completeness. $(\mathcal{P}, d)$ is a complete metric space.
• (A2) Gap–distance comparability. Near the fixed point there exist $0 < \alpha \le \beta$ with $\alpha\, d(p, p^\star) \le g(p, u^\star) \le \beta\, d(p, p^\star)$. The gap is a faithful, bounded proxy for how far the plan is from the one the user will accept.
• (A3) Contraction. There is a modulus $L \in [0, 1)$ with $d\big(S(p), S(q)\big) \le L\, d(p, q)$ for all $p, q$ in a neighborhood of $p^\star$. Read plainly: each refine round closes a constant fraction of the remaining gap. A capable proposer resolves the dominant defect the user names and does not reintroduce settled ones, so the residual set of complaints shrinks by a factor each round.

(A3) is the substantive assumption, and we are candid that it is an assumption, not a theorem about language models. It is motivated — not proven — by the observed monotone improvement of iterative self-refinement [Madaan 2023], by verbal-reinforcement refinement loops [Shinn 2023], by self-debugging convergence in code [Chen 2023], and by pipeline-level iterative optimization results [Xue 2025]. The guarantee of correctness comes from the human gate; (A3) only explains the loop's speed.

Proposition (bounded refinement). Under (A1)–(A3), $S$ has a unique fixed point $p^\star$ in the neighborhood, the iterates $p_{k+1} = S(p_k)$ converge to it, and the intent-gap decays geometrically:

Consequently, to reach an approval tolerance $g \le \tau$ it suffices to run

Proof sketch. By (A3), $S$ is a contraction on a complete space, so the Banach fixed-point theorem [Banach 1922] yields a unique $p^\star$ and the geometric bound $d(p_k, p^\star) \le L^k\, d(p_0, p^\star)$. Apply the lower and upper comparabilities of (A2): $g(p_k, u^\star) \le \beta\, d(p_k, p^\star) \le \beta L^k d(p_0, p^\star) \le (\beta/\alpha) L^k g(p_0, u^\star)$. Setting the right side $\le \tau$ and solving for $k$ gives $k^\star$. $\blacksquare$

The practical reading: with a gap-reduction factor of, say, $L = 0.5$ [illustrative], a plan that starts three "halvings" away from acceptable is approvable in three rounds. Refinement dialogues are short by construction of a competent operator, not by luck.

Remark (moving intent). Mixed-initiative refinement often teaches the user, so $u^\star$ is not fixed — the founder discovers what they meant by watching the diffs [He 2026]. Treat the intent as a sequence $u_k \to u^\star$. If the intent updates are themselves diminishing (each disclosure smaller than the last), the coupled iteration is a perturbed fixed-point scheme whose error is bounded by the sum of a geometric term and the tail of the intent perturbations; convergence survives as long as the perturbations are summable. The loop tolerates a user who is still making up their mind — it just takes a few more rounds. Trust in such planners rises precisely when the user can see and steer this process [Chen 2025], which is why the diff is visible rather than silent.

7.3 Algorithm

The loop is a guarded state machine. Its one non-negotiable invariant: the edge into execution is reachable only through approve.

Plain Text
23 lines
Copy
Algorithm RefineLoop
Input:  intent seed s, stage σ, tolerance τ, max rounds K
Output: approved plan p*  |  ABORT

 1  p ← Propose(s, σ)                      # agentic planning — hidden, side-effect-free
 2  render(p) as ProposedPlan in artifact pane        # branded "Review & Refine"
 3  k ← 0
 4  loop:
 5      a ← AwaitUserAction()              # a ∈ { approve, refine(f), abort }
 6      if a = approve:
 7          for step in p.steps:           # THE ONLY EDGE INTO SIDE EFFECTS
 8              dispatch(step) → UNO POST /api/v1/dispatch    # 5-gate broker, then BullMQ
 9          return p                        # human gate = ground truth
10      if a = abort:
11          return ABORT
12      if a = refine(f):
13          p' ← T(p, f, σ)                # live-refactor; still inert
14          Δ  ← Diff(p, p')               # PlanDiff, with estimated gapDelta ≤ 0
15          render(Δ) in place             # the VISIBLE diff
16          p ← p';  k ← k + 1
17          if k ≥ K:                       # bound the argument
18              summarize(p); suggest scope-cut or escalate-to-human-expert
19  end loop

Two design notes. First, Propose and T are the same engine invoked with different priors — a fresh plan is the empty-feedback case of refinement — which is why the interface presents one verb, "refine," and never a mode switch. Second, the automated fitness gate of ideation (the EvaluatorService rubric, keep iff score $\ge 60$, see §2) and this human intent gate are different gates in series: the machine filters candidates for quality; the human ratifies fit. The Refine Loop is the second, and it is the one that cannot be automated away.

7.4 Code patterns

A plan is never opaque prose. It is a typed, inspectable artifact, so the diff can be computed structurally and the gate can be enforced by the type system.

TypeScript
22 lines
Copy
// A proposed plan: legible structure, not a wall of text. Rendered into the
// artifact pane; every step is a would-be UNO dispatch that is NOT yet fired.
interface ProposedPlan {
  planId: string;
  stage: 'catalyst' | 'thesis' | 'crucible' | 'apex';
  intentDigest: string;                 // the system's paraphrase of what it heard
  steps: PlanStep[];
  rationale: string;                    // plain-language "why" — engine stays hidden
  revision: number;                     // monotone; increments once per refine round
  status: 'proposed' | 'refining' | 'approved' | 'aborted';
}

interface PlanStep {
  stepId: string;
  title: string;
  summary: string;
  // Compiles to a gated dispatch — but is dispatched ONLY after approval.
  dispatch?: Pick<DispatchRequest,
    'jobType' | 'inputParams' | 'appId' | 'pluginId'>;
  reversible: boolean;                  // irreversibles surfaced explicitly to the user
  estimate?: { tokens?: number; wallSeconds?: number };   // [illustrative]
}

The diff is a first-class value. It carries a gapDelta — an estimate of the change in the intent-gap $g$ — so the surface can show the user that a refinement moved them closer (the estimator is an LLM-as-judge scoring residual mismatch, in the manner of G-Eval-style rubrics [Liu 2023]; it informs the UI, never the gate).

TypeScript
12 lines
Copy
type StepChange =
  | { op: 'add';     step: PlanStep }
  | { op: 'remove';  stepId: string }
  | { op: 'modify';  stepId: string; before: Partial<PlanStep>; after: Partial<PlanStep> }
  | { op: 'reorder'; stepId: string; fromIndex: number; toIndex: number };

interface PlanDiff {
  fromRevision: number;
  toRevision: number;
  changes: StepChange[];
  gapDelta: number;    // estimated Δg; the loop expects gapDelta ≤ 0 (progress)
}

Finally, the guarded transition. The invariant "execution is unreachable except through approve" is legible in the return type: executed can be true on exactly one branch.

TypeScript
33 lines
Copy
type RefineAction =
  | { kind: 'approve' }
  | { kind: 'refine'; feedback: string }   // conversational, natural language
  | { kind: 'abort' };

interface RefineStepResult {
  plan: ProposedPlan;
  diff?: PlanDiff;         // present only on 'refine'
  executed: boolean;       // true ONLY on the 'approve' branch
}

async function refineStep(
  plan: ProposedPlan,
  action: RefineAction,
  ctx: RefineContext,
): Promise<RefineStepResult> {
  switch (action.kind) {
    case 'abort':
      return { plan: { ...plan, status: 'aborted' }, executed: false };

    case 'refine': {
      const next = await applyRefinement(plan, action.feedback, ctx); // T(p, f)
      const diff = computeDiff(plan, next);                           // Diff(p, p')
      return { plan: { ...next, status: 'refining' }, diff, executed: false };
    }

    case 'approve': {
      // The one edge into side effects: each step → gated UNO dispatch.
      await Promise.all(plan.steps.map((s) => ctx.dispatch(s))); // POST /api/v1/dispatch
      return { plan: { ...plan, status: 'approved' }, executed: true };
    }
  }
}

Because applyRefinement and computeDiff never call ctx.dispatch, a reader — or a static check — can verify by inspection that no plan reaches UNO without traversing the approve case. The safety property is not a convention; it is a shape.

7.5 Why this is the most important step

Nexus Axiom is a pipeline: Catalyst feeds Thesis, Thesis feeds Crucible, Crucible feeds Apex, and re-entry loops back through all of them (see §2–§5). Each stage consumes the previous stage's output as its input. That is exactly the structure in which small errors do not add — they multiply.

Model it. Let stage $i$ preserve a fraction $\rho_i \in (0,1]$ of the founder's intent at its gate. With no correction, end-to-end fidelity is the product

which decays geometrically: four stages at $\rho_i = 0.9$ each land at $\Phi \approx 0.66$ — a third of the intent lost to compounding drift, and the founder receives a live product that is subtly not the thing they asked for. Now insert a Refine Loop at every gate. Each loop drives its stage's residual below tolerance, $\rho_i \ge 1 - \varepsilon_i$ with $\varepsilon_i \le \tau$. Then

The loop converts multiplicative drift into additive, bounded drift — the difference between error that explodes across stages and error that merely accumulates linearly and stays small. This is the compounding-gate argument, and it is why the Refine Loop earns flagship billing: it is the only component whose quality multiplies through the entire venture-building pipeline. Improve the ideation engine and you improve one stage; improve the Refine Loop and you improve the coupling between all of them.

There is a second-order benefit. Because each approved plan is a legible artifact with a recorded refinement history, every gate leaves a trace of why the founder chose what they chose — signal that feeds the Pattern Learning Substrate as generalized, IP-firewalled experience (see §8), and that seeds the re-entry loop when the founder returns to pivot (see §5). The loop does not merely prevent drift in one build. It compounds understanding across builds.

The engine stays invisible. The loop stays plain. The human stays in charge. That combination — hidden sophistication behind a legible, refuse-able proposal — is what lets a raw idea become a sovereign, live product without the founder ever ceding control to a machine they cannot see. Plan mode, generalized into a venture builder.

---

8. The Pattern Learning Substrate & IP Firewall

Nexus Axiom does not build from a blank slate. Every venture it ships stands on a decade of prior Adverant platforms — their service topologies, their dispatch contracts, the failure modes they hit in production, the particular shape of a well-formed tenant cell. The Pattern Learning Substrate (which we label $V_p$, the substrate cross-referenced throughout) is the mechanism that turns that accumulated experience into retrievable, reusable structure. It is also the paper's sharpest tension. The flywheel only spins if the system learns from what it has already built; yet the plugin-independence thesis (see V1) makes cross-customer confidentiality non-negotiable. The IP firewall is how both hold at once: the substrate emits original applications assembled from generalized patterns, never verbatim proprietary source and never one customer's code into another customer's product.

8.1 Role in the flywheel

Two consumers pull from the substrate, and only two. Ideation (see §2) queries it for architectural precedent — how have comparable two-sided marketplaces structured their settlement path? which scaling posture did prior high-write workloads settle on? — to seed hypotheses and to arm the Red Queen critic with grounded counterexamples. Code generation (see §4) queries it for implementation idiom: the canonical shape of a BullMQ worker, an edge-SSR brand resolver, a KEDA-scaled queue consumer, a five-gate broker call. Both consumers receive the same object — a generalized pattern — never a source file.

Indexing is performed by nexus-reposwarm, which walks prior-platform repositories and emits an abstracted representation into nexus-graphrag. We build on graph-structured retrieval deliberately: architecture is relational, not a bag of snippets, and the questions that matter ("what depends on the dispatch broker, and how do those dependents degrade when it is slow?") are traversal questions. Graph RAG answers query-focused, global-structure questions that flat vector retrieval answers poorly [Edge 2024]; graph-native retrievers ground multi-hop reasoning over connected entities [He 2024, Sun 2024]; and neurobiologically-inspired and lightweight graph memories keep such indexes cheap to maintain and update [Gutierrez 2024, Guo 2024]. The substrate is a memory about systems, so it is stored as a graph of systems.

8.2 Two channels of leakage, and which one we close by construction

Let $\mathcal{S} = \{r_1,\dots,r_n\}$ be the set of source repositories, each owned by exactly one tenant through the ownership map $t(r_i)$. A generation request arrives on behalf of a target tenant $\theta$, and produces output $o$. Leakage is any event in which identifiable proprietary content of some $r_i$ with $t(r_i)\neq\theta$ appears in $o$. There are exactly two channels by which it could:

1. The weight channel. If model parameters were trained or fine-tuned on customer code, that code can be memorized and later extracted — the phenomenon documented across the memorization literature: unintended memorization is measurable and testable [Carlini 2019], training data can be extracted from a deployed model [Carlini 2021], the amount memorized scales log-linearly with model capacity, example duplication, and prompt context [Carlini 2023], extraction remains feasible even against aligned production systems [Nasr 2023], and the extracted content can be verbatim copyrighted text [Karamolegkou 2023].
2. The retrieval channel. Even with clean weights, a retrieval system can hand a verbatim source chunk to the generator as context, which then copies it into the output.

We close channel 1 by construction. $V_p$ is retrieval-only; it never contributes gradients to any model's weights. Customer code is never a training target, so the extraction attacks above have no weight surface to act on — the strongest possible defense against a class of attack is to remove the attack's substrate entirely. What remains is the retrieval channel, and the rest of this volume is the discipline that bounds it: index-time abstraction, deduplication, an output-side reproduction check, and absolute tenant isolation. We treat the memorization results not as risks we merely mitigate but as the precise reason the substrate is retrieval-only and firewalled rather than a fine-tune.

8.3 The generalization transform

The firewall's first line is that nothing concrete is ever indexed. A generalization operator

maps a concrete artifact $a$ (a file, a service, a module) to a generalized pattern $p$ that retains structure — component roles, interface shapes, dependency edges, the scaling and failure semantics — while stripping the identifying specifics: literals, secrets, tenant names, business logic, domain vocabulary, and any string that could re-identify a source. Generalization is admission-controlled. A pattern is eligible for the shared index only if it satisfies at least one of:

• Cross-tenant support. Its support $\sigma(p) = \bigl|\{\, t(r) : p \sqsubseteq r,\; r\in\mathcal{S} \,\}\bigr| \ge k$ — the pattern is exhibited independently by at least $k$ distinct tenants ($k\ge 3$ in practice). A structure that $k$ independent teams converged on is an idiom, not any one customer's invention; this is a $k$-anonymity-style guarantee at the level of architecture.
• Consent-gated abstraction. The source tenant has explicitly consented to contribute generalized learnings, and the artifact has passed the abstraction pass and the reproduction check of §8.5.

Consent is a hard precondition, recorded per repository; a repository with no consent record is never walked by nexus-reposwarm. The record we store is deliberately thin:

TypeScript
15 lines
Copy
/** An index-time record. It holds NO source text — only abstracted structure. */
interface GeneralizedPattern {
  patternId: string;                 // content hash of the abstracted form
  kind: 'service' | 'module' | 'interface' | 'dataflow' | 'scaling' | 'ci';
  role: string;                      // e.g. "queue-consumer", "edge-brand-resolver"
  // Structure only — shapes, not implementations:
  interfaces: InterfaceShape[];      // names generalized, types preserved
  dependencies: DependencyEdge[];    // role-to-role edges, no identifiers
  semantics: { scaling?: string; failureModes?: string[]; invariants?: string[] };
  crossTenantSupport: number;        // σ(p): count of DISTINCT contributing tenants
  provenance: 'multi-tenant-idiom' | 'consented-abstraction';
  // Hard guarantees enforced at write time:
  containsLiterals: false;           // abstraction pass strips all literals/secrets
  sourceTenantIds: never;            // source identity is NEVER persisted on the pattern
}

Two properties are worth stating plainly. The record carries no source text — only shapes and edges. And it carries no back-pointer to the tenants it came from: once a pattern is admitted, its provenance is a category (multi-tenant-idiom or consented-abstraction), never a list of customers. There is nothing on a GeneralizedPattern to leak.

8.4 Deduplication bounds memorized specificity

Even structure-only patterns can carry residual specificity if a rare artifact appears many times across the corpus and thereby dominates retrieval. The memorization literature is unambiguous on the lever here: duplication is the single strongest predictor of regurgitation. Sequences duplicated many times are reproduced at rates far above unique sequences, and deduplicating the corpus reduces extractable memorization roughly in proportion to the duplication removed [Kandpal 2022], with the log-linear dependence on duplicate count confirmed at scale [Carlini 2023]. We therefore deduplicate at index time. Let $c(p)$ be the number of near-duplicate instances of an abstracted pattern; the substrate collapses them to a single canonical node and records $\sigma(p)$ (distinct-tenant support) rather than raw multiplicity. Retrieval salience is a function of $\sigma$, not of $c$, so no single heavily-copied artifact can dominate what the generator sees. Deduplication does double duty: it is a privacy control and a quality control, because it is generality — cross-tenant recurrence — that we want to reward, not repetition.

8.5 The output-side reproduction check

The last line of defense sits after generation, on the emitted artifact itself, and it assumes the previous lines failed. Given output $o$ and the source corpus $C$ (held in a check-only store, never a retrieval store), define a reproduction score over contiguous token runs:

where $\mathrm{LCR}_{\ell}$ is the longest common contiguous token run of length at least $\ell$ (short shared runs — language keywords, standard boilerplate — are ignored below $\ell$). The gate rejects any output with

for a conservative threshold $\tau$. This is the operationalization of the copyright-reproduction concern [Karamolegkou 2023]: rather than trust that abstraction was perfect, we measure verbatim overlap against the very sources the pattern was derived from and refuse to emit anything that reproduces them. A rejected output is regenerated under a stronger abstraction instruction; repeated rejection escalates to a human waypoint. The gate is cheap, deterministic, and — crucially — independent of the generator, so a mistake upstream cannot silently pass.

TypeScript
18 lines
Copy
/** Runs AFTER generation, BEFORE emission. Deterministic, generator-independent. */
interface ReproductionCheck {
  rho: number;                 // ρ(o, C): max normalized contiguous overlap
  tau: number;                 // rejection threshold
  crossTenantHit: boolean;     // true if the closest match belongs to t(r) ≠ θ
}

function reproductionGate(
  output: string,
  targetTenant: string,           // θ
  corpus: CheckOnlyCorpus,        // never used for retrieval — only for this check
): { pass: boolean; check: ReproductionCheck } {
  const { rho, closestSource } = longestContiguousOverlap(output, corpus, /*ell*/ 40);
  const crossTenantHit = closestSource.tenantId !== targetTenant;
  // Cross-tenant reproduction is a hard fail regardless of magnitude.
  const pass = crossTenantHit ? rho === 0 : rho <= corpus.tau;
  return { pass, check: { rho, tau: corpus.tau, crossTenantHit } };
}

Note the asymmetry in the gate: within-tenant reuse tolerates overlap up to $\tau$ (a customer may legitimately see idioms from its own prior work), but any cross-tenant contiguous match — $\rho>0$ against a source with $t(r)\neq\theta$ — is an unconditional failure. Cross-customer isolation is not a threshold; it is absolute.

8.6 Algorithms

The two operations of the substrate, with the firewall inlined at every stage where source content could otherwise escape.

Plain Text
15 lines
Copy
Algorithm  IndexWithFirewall
Input:  repository r, consent record κ(r)
Output: admitted GeneralizedPattern nodes written to nexus-graphrag
 1: if κ(r) is absent or revoked: return ∅          # consent is a hard precondition
 2: A ← walk(r)                                      # nexus-reposwarm enumerates artifacts
 3: P ← ∅
 4: for each artifact a in A:
 5:     p ← g(a)                                     # abstract: strip literals/secrets/identity
 6:     if containsIdentifiableContent(p): continue  # fail-closed: drop, do not index
 7:     p ← deduplicateInto(P, p)                    # collapse near-duplicates; update σ(p)
 8:     P ← P ∪ {p}
 9: for each p in P:
10:     if σ(p) ≥ k  OR  (κ(r).abstractionConsent AND reproductionSafe(p)):
11:         writeNode(nexus-graphrag, p)             # NO sourceTenantIds persisted
12: return P

Plain Text
13 lines
Copy
Algorithm  QueryWithFirewall
Input:  query q, target tenant θ, retrieval budget b
Output: emitted artifact o, or human-escalation
 1: G ← graphRetrieve(nexus-graphrag, q, budget=b)   # generalized patterns only
 2: G ← { p ∈ G : provenance(p) ≠ 'raw' }            # invariant: nothing raw is retrievable
 3: o ← generate(q, context=G)                       # code-gen (§4) or precedent (§2)
 4: (pass, chk) ← reproductionGate(o, θ, C)          # output-side check, §8.5
 5: if not pass:
 6:     if chk.crossTenantHit: return ESCALATE       # cross-tenant hit ⇒ hard stop
 7:     o ← generate(q, context=G, strongerAbstraction=true)   # regenerate once
 8:     (pass, _) ← reproductionGate(o, θ, C)
 9:     if not pass: return ESCALATE                 # human waypoint
10: return o

Both algorithms are fail-closed: the default action on any ambiguity — absent consent, identifiable residue, a reproduction hit — is to drop or to stop, never to emit. The firewall's correctness does not depend on the generator behaving well.

8.7 Cross-customer isolation is absolute

The isolation guarantee is enforced at three layers, so that no single failure is load-bearing. At index time, only consented repositories are walked, and only structure that survives abstraction and (for single-source patterns) the reproduction check is written — and it is written without any source-tenant identity attached (§8.3). At retrieval time, the store contains generalized patterns only; there is no raw-source retrieval path to traverse, which is the difference between a shared learning substrate and a shared data substrate. At emission time, the reproduction gate treats any cross-tenant contiguous match as an unconditional failure (§8.5).

This is a stricter posture than pooled multi-tenant retrieval, where tenants share an index and isolation is a matter of query-time filtering and noisy-neighbour management [Kumar 2026]. Nexus Axiom deliberately does not pool customer code: the shared object is the generalized pattern, which by construction belongs to no one, while each customer's actual source lives only in its own sovereign cell (its own repository, namespace, and database — see §4). The classical multi-tenancy design space trades isolation against sharing along a known spectrum [Chong 2006, Ochei 2018], and performance isolation for shared stores is itself a hard problem [Shue 2012, Zheng 2021]. We sidestep the sharpest version of that trade-off by sharing only abstractions and keeping every concrete asset siloed. Isolation is not tuned; it is structural.

8.8 The flywheel, and what it does not claim

The substrate is a compounding asset. Each shipped venture, once consented, contributes generalized idioms that make the next venture's ideation better grounded and its scaffolding faster to emit; deduplication and cross-tenant support ensure the index rewards generality rather than accumulating a customer's private specifics. That is the flywheel: more ventures built produces better patterns, which produces better ventures, behind a firewall that never widens.

Three limits are worth stating without hedging. First, generalization is lossy by design — a pattern is not a solution, and the generator still does the work of instantiating original code for the target ($V_p$ informs §4, it does not replace it). Second, the reproduction check bounds verbatim contiguous overlap; it does not certify semantic non-infringement, which remains a human-reviewed concern at the gate. Third, we claim an architecture for anti-reproduction, grounded in the memorization literature's account of how leakage happens and what suppresses it [Carlini 2019, Carlini 2021, Carlini 2023, Kandpal 2022, Nasr 2023, Karamolegkou 2023]; we report no empirical extraction-rate measurements here, and none should be read into the design. The guarantee we do make is the structural one: customer code is never trained on, never retrievable in the raw, and never emitted across a tenant boundary.

---

9. The Deliverable Artifact Library (PID)

A venture that reaches Apex is not merely a running product — it is a documented enterprise. Nexus Axiom holds that a customer who commissions a company should receive everything a diligent human founding team would have produced along the way: the governance record that justified the build, and the built things themselves. We call this complete set the PID — borrowing, deliberately, the PRINCE2 term Project Initiation Documentation, the baseline set of management products assembled at a project's outset to establish why it exists, what it will deliver, and how it will be controlled [AXELOS 2017]. Here we widen the term: the PID is the whole per-venture artifact library, spanning both the PRINCE2-style initiation documents and the concrete deliverables catalog — the architecture papers, the go-to-market strategy, the patents, the mockups, the documentation, and the deployed app and marketing site that are the venture's reason to exist.

This volume specifies that library: its two registers, a schema and provenance model for each record, and the discipline by which every artifact is committed to the customer's own forge repository (see §4, §5). Nothing here is new machinery so much as it is a view over machinery already built. The versioned artifact graph $G=(A,D)$ of §5 already holds every derived object of a venture; the PID is the customer-facing projection of $G$ — the subset of $A$ that is a deliverable, materialized, provenance-stamped, and indexed.

9.1 Two registers over one graph

The library has exactly two registers, and every deliverable belongs to precisely one.

The initiation register is the PRINCE2-style Project Initiation Documentation: the business case (the grounded hypothesis and its evidence, distilled from Catalyst and Thesis, see §2–§3), the project plan and timeline (the orchestration DAG UNO will execute, rendered as a schedule), the risk register (enumerated risks with probability, impact, and mitigation, drawn from the research dossier and from Alive's SLO/error-budget model, see §5), the quality plan (the acceptance rubric — the EvaluatorService five-dimension score with its keep-threshold, plus the Forgejo build → trivy → cosign gates that a release must clear, see §4), and the stakeholder map. The stakeholder map records customer-declared roles and their decision rights only; consistent with the psychometric wall (see §1), it never contains a psychometric read of a real named individual.

The catalog register is the deliverables themselves: the architecture paper (an ASCII-diagram atlas of the venture's own application, GraphRAG-grounded against the Pattern Substrate [Edge 2024], and scoped by the IP firewall to the venture's surface — never the shared brain's internals, see §8), the GTM strategy (positioning, segmentation, and the Monte-Carlo P&L of §10), the patent set (the provisional filings of the portfolio volume), the UI/UX mockups (ASCII renderings of every surface, from the design system of §6), the app-only architecture diagrams, the support and user documentation, and — the two artifacts that are not documents but products — the deployed app and the marketing site, each an OCI image and a git tag rather than a file (see §4).

Both registers are drawn from the same graph, so both inherit its guarantees: content-addressing, derivation edges, and Merkle-rooted versioning. The split is organizational, not architectural.

9.2 The DeliverableRecord and its provenance

Each entry in the library is a DeliverableRecord: an index row that points at the materialized artifact and carries the evidence of how it came to be. The record reuses the §5 primitives directly — the Stage that owns it, the content hash $h(a)$ that also serves as its Merkle leaf, the GateApproval that admitted it, and the KbCardDef that the inspector renders (see §4). It adds one thing §5 did not need: an explicit provenance block, because a customer who owns a company must be able to audit not just what was produced but by what and from what.

TypeScript
40 lines
Copy
type Register = 'initiation' | 'catalog';   // PID split: PRINCE2 governance vs built deliverables

type DeliverableKind =
  // Initiation register — PRINCE2-style PID
  | 'business-case' | 'project-plan' | 'risk-register'
  | 'quality-plan'  | 'stakeholder-map'
  // Catalog register — the built deliverables
  | 'architecture-paper' | 'gtm-strategy' | 'patent-set'
  | 'ui-mockups' | 'app-architecture-diagram'
  | 'user-docs' | 'deployed-app' | 'marketing-site';

type SerialFormat =
  | 'markdown' | 'json' | 'yaml' | 'ascii' | 'svg' | 'oci-image' | 'git-tag';

interface Provenance {
  generator: string;          // owning engine id (Catalyst/Thesis/GTM/Patent/Atlas/…)
  producedBy: Stage;          // reuse §5 Stage
  derivedFrom: string[];      // upstream artifact ids — the edges of D (see §5)
  refineIterations: number;   // propose→refine→approve rounds that shaped it (see §7)
  frontierSynthesis: boolean; // true iff drafted on frontier Anthropic @ max-thinking
  patternIds: string[];       // generalized §8 patterns used — never verbatim source
  attestation: string;        // in-toto-style signed link over materials→product
}

interface DeliverableRecord {
  id: string;
  ventureId: string;
  register: Register;
  kind: DeliverableKind;
  title: string;
  format: SerialFormat;
  repoPath: string;           // path inside the venture's OWN forge repo (§4/§5)
  contentHash: string;        // h(a): sha256 of canonical serialization = §5 Merkle leaf
  provenance: Provenance;
  gate: GateApproval | null;  // human approval that admitted it (§7); null ⇒ candidate
  version: string;            // PlanVersion.versionId this record belongs to (§5)
  status: 'candidate' | 'approved' | 'committed' | 'stale';
  card: KbCardDef;            // inspector rendering (§4); absent field ⇒ "—", never fabricated
  createdAt: string;          // ISO 8601
}

Two fields carry the paper's guardrails. patternIds names the generalized Pattern Substrate blocks a deliverable was composed from, never verbatim proprietary or cross-customer source — the IP firewall made auditable at the row level (see §8). And attestation is a cryptographic link, in the in-toto sense, binding the declared input materials (derivedFrom) to the produced artifact ($h(a)$), so that the supply chain from hypothesis to shipped file is independently verifiable rather than merely asserted [Torres-Arias 2019]. The attestation is signed with the same cosign key that the Forgejo pipeline already uses to sign the venture's OCI images (see §4), so provenance for the documents and provenance for the deployed app share one trust root.

9.3 Materialization and commit

The library is not a side effect; it is materialized by an explicit pass over the live version and committed, in full, to the venture's own repository. Because a deliverable's canonical serialization is content-hashed with the same function that produces the §5 Merkle leaves, every record's content hash must equal its §5 Merkle leaf $h(a)$ — a cheap, per-record consistency check that the library faithfully mirrors the venture state it claims to describe. Because the registry is a deliverable-only subset of the graph, its hashes need not reconstruct the whole version root $H(v)$, which ranges over every reachable artifact.

Plain Text
21 lines
Copy
Algorithm 9.1  MaterializeDeliverableLibrary
Input:  live version v with graph G=(A,D) (see §5); repo (venture-owned forge)
Output: deliverable registry R, committed to repo; or ABORT with reason

 1  R ← ∅
 2  for each artifact a ∈ reach(v) in topologicalSort(A, D) do
 3      k ← classify(a)                       // DeliverableKind, or ⊥
 4      if k = ⊥ then continue                // internal artifact, not customer-facing
 5      fmt ← canonicalFormat(k);  s ← serialize(a, fmt)
 6      h   ← sha256(s)                       // = the §5 Merkle leaf for a
 7      prov ← provenanceOf(a)                // generator, derivedFrom, patternIds, refineIters
 8      assert firewallClean(s, prov)  else ABORT "IP-firewall: verbatim/cross-tenant leak"
 9      assert gateOf(a) ≠ null        else ABORT "ungated deliverable"   // every artifact is gated (§7)
10      path ← layout(register(k), k)         // e.g. _pid/initiation/… or docs/architecture/…
11      writeFile(repo, path, s)
12      att ← intotoLink(step=k, materials=prov.derivedFrom, products=[h])
13      cosignSign(att)                       // same signer as the §4 image pipeline
14      R ← R ∪ { DeliverableRecord(a, k, path, h, prov, card = kCard(a)) }
15  writeFile(repo, "_pid/manifest.json", index(R))     // the registry itself
16  assert ∀ record∈R: record.contentHash = leaf_v(record.artifact)  else ABORT "registry drift vs version"
17  commit(repo, R);  return R

The commit destination is load-bearing. The library lands in the customer's forge repository (see §4, §5), on the same GitFlow lineage as the code, under a stable _pid/ layout with a manifest.json index at its root. A customer who later leaves with their repository leaves with the entire evidentiary record — business case, risk register, patents, mockups, and app alike — because ownership of the venture means ownership of its documentation, not a rented view of it. There is no Adverant-hosted registry that must be exported; the registry is files in a repository the customer already holds.

9.4 Completeness, staleness, and the inspector

Two properties close the loop. First, completeness is total, and gaps are honest. The registry ranges over every deliverable-classified artifact in $\mathrm{reach}(v)$; a deliverable that has not yet been produced or approved has a record with status: 'candidate' and a card whose value fields are absent — which renderKbCard displays as "—" (see §4), never as an invented placeholder. A founder reading the inspector sees exactly which deliverables exist and which are still owed, at the same granularity the paper insists on everywhere: the platform renders the gap rather than filling it.

Second, the library re-enters with the venture. A pivot edits some $\Delta \subseteq A$ and invalidates its stale cone of influence $C(\Delta)$ (see §5). Every DeliverableRecord whose artifact lies in $C(\Delta)$ is flipped to status: 'stale' and re-materialized on the next pass of Algorithm 9.1; every record outside the cone carries forward untouched, its content hash and attestation still valid. So a change to the brand palette re-mints the mockups and the marketing site but not the patent set; a change to the hypothesis re-mints nearly the whole library, and correctly so. The deliverable library is therefore not a one-time export produced at launch and left to rot — it is a live, versioned, provenance-stamped reflection of the venture, as current as the last approved commit and as auditable as the chain that produced it.

---

10. Economics & Go-To-Market Model

This volume specifies the economic model and go-to-market (GTM) framework of a Nexus Axiom venture — not its forecast. The distinction is load-bearing. A forecast is a single trajectory; a model is the generative structure that produces a distribution of trajectories once a user supplies drivers. The concrete, calibrated numbers for any given venture live in a separate GTM blueprint that instantiates this model against a real market. Here we give the machinery: how customers are segmented, how the venture is priced and packaged, how unit economics are derived from a $0-start funnel rather than assumed, and how a correlated Monte-Carlo engine turns a ledger of driver assumptions into a P10/P50/P90 P&L. Every specific figure that appears below is tagged [illustrative]: it exists to exercise the arithmetic, and no number is cross-applied from any other company.

The organising principle is that a Nexus Axiom forecast is a parametric hypothesis model. Let $\theta$ be the vector of user-supplied drivers (traffic, conversion rates, ARPA, retention, spend, unit COGS). Then every reported financial quantity is a function $g(\theta)$ — deterministic given $\theta$, uncertain only because $\theta$ is uncertain. This makes the economics falsifiable in the same sense the rest of the paper insists on: change an input, and the whole P&L recomputes; observe an actual conversion rate in the Apex stage, and the corresponding marginal collapses to a point mass. The model is not a pitch; it is an instrument that turns beliefs into consequences.

10.1 Customer segmentation: generalized psychometric personas

Segmentation feeds two internal machines: the message posture the venture's own agents adopt when composing outbound copy, and the evaluator priors (see §2, Ideation) that rank ideation candidates by fit to a target buyer. Both are internal. Per the psychometric wall, personas are generalized archetypes — never models of, or assertions about, any real, named individual — and the segmentation surface never leaves the system as a claim about a person.

We scaffold personas with a two-layer heuristic: a behavioural-style axis derived from Marston's four-factor model of behavioural styles [Marston 1928], in the four-quadrant DISC rendering later adapted from it — Dominance, Influence, Steadiness, Conscientiousness — composed with Cialdini's principles of influence as the persuasion lever most likely to resonate with each quadrant [Cialdini 1984]. We are explicit that the behavioural-style layer is a heuristic organizing scaffold, not a validated psychometric instrument, and its predictive validity is not asserted; it earns its place only as an internal routing prior that the EvaluatorService and the Pattern Learning Substrate (see §8, the Pattern Substrate, and §12, Patents) continuously correct against observed outcomes.

The mapping is consumed by the CMA's 13 patterns on nexus-graphrag as a retrieval facet — "surface prior wins with Analyst-shaped buyers" — and as a weight on the ideation preference model. It is never surfaced as a verdict about a prospect. When a persona field is unknown, it renders as — in the InspectorPane exactly as any other missing k-card value (see §4, Deploy), which keeps absence honest rather than imputed.

10.2 Pricing and packaging

Packaging follows the house schema convention: a tiered subscription with an included monthly credit grant, per-seat pricing on top of the base tier, usage-metered add-ons that draw down credits, and Stripe as the billing rail. Credits are the metering primitive that lets the venture pass through the marginal cost of frontier inference — research and ideation run on frontier Anthropic models at maximum thinking budget (see §2, Ideation, and §7, the Refine Loop), which is a real, variable COGS that must be metered rather than absorbed. A seat grants access; a credit funds an AI action; an add-on unlocks a capability class. This separates the right to use from the cost to serve, so gross margin is defensible even as usage mixes shift.

TypeScript
19 lines
Copy
type BillingInterval = "monthly" | "annual";

interface PricingTier {
  id: string;                         // "starter" | "growth" | "scale"
  basePrice: number;                  // per interval, tenant currency
  interval: BillingInterval;
  includedCredits: number;            // monthly grant; resets each cycle
  includedSeats: number;
  perSeatPrice: number;               // marginal seat above included
  overageCreditPrice: number;         // price per credit beyond grant
  addOns: UsageAddOn[];               // capability-gated meters
  stripePriceId: string;
}

interface UsageAddOn {
  meter: string;                      // "deep_research_run" | "deploy_cell"
  creditCost: number;                 // credits drawn per event
  hardCapPerCycle?: number;           // guardrail against runaway spend
}

A distinctive lever is the NexusROS-as-GTM-tool bundle: the venture is offered a time-boxed grant of the account-intelligence engine that the platform itself uses to sell — a "sell with the weapon we sell with" motion. Concretely, a new customer receives a bounded window (e.g. 60 days [illustrative]) of elevated credit allowance earmarked for GTM workloads (target research, buying-committee mapping, ABM asset drafting), after which the allowance reverts to the standard tier grant. The bundle is a land instrument: it front-loads value at the moment of highest intent and depends on nothing outside the credit machinery already described — it is a scheduled modifier on includedCredits, not a separate product. Time-boxing is what keeps it a promotion rather than a permanent margin leak.

The packaging is deliberately land-and-expand: the base tier must be crossable at $0 marginal friction (self-serve trial), and expansion is monetized through seats (team adoption), credits (usage depth), and add-ons (capability breadth) — three orthogonal expansion vectors so net revenue retention does not depend on any single behaviour.

10.3 Bottom-up unit economics from a $0-start

We refuse top-down TAM arithmetic. Unit economics are built from a funnel whose every stage is a driver in $\theta$, and CAC, LTV, and payback are outputs of that funnel, not inputs. Let a period deliver $V$ visitors. Define trial rate $\tau$, activation rate $\alpha$ (share of trials reaching the activation event), and activated→paid conversion $\kappa$. Then

Customer acquisition cost is spend divided by that yield — so CAC falls automatically as any funnel stage improves, which is the entire point of deriving rather than assuming it:

Lifetime value follows from monthly retention $r$ (churn $c = 1-r$), monthly ARPA $A$, gross margin $m$, and a monthly discount rate $\delta$. Treating a cohort as a geometric survival stream and discounting,

In the undiscounted limit $\delta \to 0$ this collapses to the familiar $\text{LTV} = A m / c$, which is the sanity check that the closed form is correct. The value of a customer as the expected sum of discounted future margin is the standard customer-equity definition, and its extreme sensitivity to retention — a small change in $r$ moves firm value far more than an equal change in discount rate or acquisition cost — is precisely why retention is the driver we instrument most carefully [Gupta 2004]. Payback is the months of contribution margin required to recover CAC:

Because every symbol is a driver, the reported LTV/CAC ratio is a consequence of assumptions the user can see and edit — not a headline number asserted for effect. A venture that wants a higher ratio must move a real lever ($\tau, \alpha, \kappa, r, A, m$) and accept the coupled effect on every other line.

10.4 The assumption ledger

The parametric model is materialized as an assumption ledger: a versioned, per-venture record of every driver, its distribution, its provenance, and the correlations among drivers. The ledger is the single source of truth the Monte-Carlo engine consumes; it is also what the InspectorPane renders, so an analyst can trace any output line back to the marginals that produced it. Provenance is first-class — a driver sourced from user_input is a hypothesis, one sourced from benchmark carries a citation, and one derived is computed from others — and a missing rationale renders as — rather than being silently filled.

TypeScript
30 lines
Copy
type Distribution =
  | { kind: "point"; value: number }
  | { kind: "triangular"; min: number; mode: number; max: number }
  | { kind: "pert"; min: number; mode: number; max: number; lambda?: number }
  | { kind: "lognormal"; mu: number; sigma: number }
  | { kind: "beta"; alpha: number; beta: number; scale: [number, number] };

interface DriverAssumption {
  id: string;                         // "trial_rate", "monthly_churn", ...
  label: string;
  unit: "rate" | "currency" | "count" | "months" | "ratio";
  dist: Distribution;                 // marginal F_j
  source: "user_input" | "benchmark" | "derived";
  rationale: string;                  // "" -> renders "—" in InspectorPane
  clamp?: [number, number];           // hard bounds applied after sampling
}

interface CorrelationEdge {
  a: string; b: string;               // driver ids
  rankRho: number;                    // Spearman target in [-1, 1]
}

interface AssumptionLedger {
  ventureId: string;
  currency: string;                   // "EUR" | "USD" | ...
  horizonMonths: number;
  seed?: number;                      // reproducible sampling
  drivers: DriverAssumption[];
  correlations: CorrelationEdge[];
}

Each Monte-Carlo iteration emits a stream of monthly P&L driver records — the auditable trace of one simulated world — from which portfolio metrics (ending EBITDA, runway, LTV/CAC) are extracted.

TypeScript
22 lines
Copy
interface PnLDriverRecord {
  month: number;
  visitors: number;
  trials: number;
  activated: number;
  newPaid: number;
  churnedPaid: number;
  activePaid: number;
  arpa: number;                       // A
  grossMarginPct: number;             // m
  newMrr: number;
  mrr: number;
  sAndMSpend: number;                 // S_S&M
  creditCogs: number;                 // frontier-inference pass-through
  opex: number;
  cac: number;                        // derived, not input
  ltv: number;                        // derived, not input
  ltvCacRatio: number;
  paybackMonths: number;
  ebitda: number;
  cashBalance: number;                // runway = first month cash < 0
}

10.5 Correlated Monte-Carlo P&L

Point estimates lie by omission: they hide the fact that a good conversion month and a good retention month tend to co-occur (both track product-market fit), so treating drivers as independent understates both upside and downside. We therefore simulate the joint distribution of $\theta$ with a Gaussian copula, which separates each driver's marginal shape from the dependence structure that binds them. By Sklar's theorem the joint law factors as $H(x_1,\dots,x_d) = C\big(F_1(x_1),\dots,F_d(x_d)\big)$, and the copula $C$ carries all the dependence [Li 2000]. The Gaussian copula makes $C$ the dependence of a latent multivariate normal, which is tractable and correlation-parameterized — with the caveat, which we take seriously, that linear correlation is only a complete dependence description under ellipticity and can mislead about tail co-movement [Embrechts 2002].

Users specify dependence as rank (Spearman) correlations, because rank correlation is invariant to each driver's marginal and is the quantity a domain expert can actually reason about. For a Gaussian copula the required latent Pearson correlation is recovered in closed form,

so a target Spearman $\rho_S$ becomes an entry of the latent correlation matrix $R$. Sampling then proceeds by Cholesky factorization $R = L L^{\top}$, correlating independent normals, mapping through the standard-normal CDF to uniforms, and inverting each marginal:

Each sampled $\mathbf x$ is a coherent draw of all drivers at once; feeding it through the funnel and cost stack yields one P&L path. The engine repeats this at least $N = 10{,}000$ times. Monte-Carlo error shrinks as $\mathcal O(N^{-1/2})$ — the standard-error of the estimated P&L mean is $\mathrm{SE} = \sigma / \sqrt{N}$, with the quantile bands converging at the same $N^{-1/2}$ rate — which is the classical convergence behaviour that makes simulation preferable to lattice methods once the driver dimension is more than a few [Boyle 1977]. Reported bands are empirical quantiles of the resulting metric distribution:

Plain Text
30 lines
Copy
CORRELATED-MC-PNL(ledger L, iterations N >= 10_000, horizon H)
  # 1. assemble latent correlation from rank targets
  R <- identity(d)
  for edge (j,k) in L.correlations:
      R[j][k] = R[k][j] = 2 * sin(pi * edge.rankRho / 6)
  # 2. ensure a valid covariance; repair to nearest PD if needed
  if not positive_definite(R):
      R <- nearest_positive_definite(R)      # Higham projection
  Lc <- cholesky(R)                           # R = Lc * Lc^T
  metrics <- []
  # 3. simulate
  for i in 1..N:
      eps  <- sample_standard_normal(d)
      z    <- Lc @ eps                         # correlated normals
      x    <- []
      for j in 1..d:
          u_j <- Phi(z[j])                     # copula -> uniform
          x_j <- inverse_marginal(L.drivers[j].dist, u_j)
          x_j <- clamp(x_j, L.drivers[j].clamp)
          x.append(x_j)
      path <- simulate_pnl(x, H)               # funnel -> revenue -> costs
      metrics.append(extract(path))            # ebitda_H, runway, ltv/cac
  # 4. summarize
  sort(metrics)
  return {
      P10: quantile(metrics, 0.10),
      P50: quantile(metrics, 0.50),
      P90: quantile(metrics, 0.90),
      SE:  std(metrics) / sqrt(N)              # standard error of the mean estimate
  }

The nearest_positive_definite step is not incidental: a matrix of independently elicited pairwise rank correlations need not be a valid covariance, and projecting to the nearest positive-definite matrix is what keeps the Cholesky step well-posed — a direct consequence of the correlation-attainability constraints [Embrechts 2002].

Two extensions are supported when a single global correlation matrix is too blunt. When systemic co-movement dominates — a macro shock that hits every driver at once — a principal-component copula concentrates dependence in a few latent factors, which is both more parsimonious and more faithful to how ventures actually fail together [Gubbels 2023]. When the dependence is asymmetric — drivers coupled in the downside tail but not the upside — a vine copula composes bivariate copulas into a flexible high-dimensional structure and, rendered as a differentiable computational graph, can be fit and differentiated end-to-end alongside the rest of the model [Cheng 2025]. The Gaussian copula is the default because it is legible; the vine is the escape hatch when legibility costs too much accuracy.

Finally, the four human gates (Catalyst, Thesis, Crucible, Apex) are genuine decision points at which a venture can be continued, re-scoped, or abandoned — an embedded sequence of real options, not a static plan. Valuing that optionality requires a path-dependent estimator, and least-squares Monte-Carlo — regressing continuation value on the simulated state at each gate to decide exercise — is the natural fit: the same simulated paths that produce the P&L fan also price the option to stop [Longstaff 2001]. The economic value of the human-gated architecture is thus not rhetorical; it is the abandonment value the simulation can quantify.

10.6 Reading the model

The output is a fan chart, not a line. P50 is the planning case; the P10–P90 spread is the honest width of what is not yet known; runway is read off the first month in which simulated cash goes negative across the percentile bands. A sensitivity (tornado) decomposition — re-running with each driver pinned to its marginal median while the rest vary — ranks drivers by how much they move the outcome, which is what tells a founder where to spend the next month buying certainty. As the venture enters Apex and real telemetry arrives, observed drivers collapse from distributions to points, the fan narrows, and the model converges on measured reality. That convergence is the economic expression of the whole paper's thesis: a hypothesis, gated by humans, refined against evidence, until the distribution over outcomes becomes a fact.

---

11. Cost & Pricing Study

A venture-builder that spends frontier reasoning tokens the way a foundry spends electricity has an unusual cost structure: its dominant line item is neither labour nor cloud compute but inference. This volume builds the unit economics of a single Nexus Axiom venture from the bottom up — priced against real, current Anthropic rates — and derives customer pricing, complexity tiers, and the sensitivity of gross margin to the one input that moves everything: the per-token price of frontier reasoning. Every hard figure is either cited to a source or tagged [illustrative]; the illustrative numbers are internally consistent and chosen so the shape of the economics is faithful even where a specific magnitude is a modelling assumption rather than a measured cost.

11.1 Why tokens dominate COGS

The AI-provider routing policy places the two most reasoning-intensive stages — co-evolutionary grounded ideation (§2) and deep grounded research (§3) — on the frontier Anthropic model at maximum thinking effort. That is a deliberate quality choice, and it makes those two stages the largest cost centre in the whole pipeline. The Refine Loop (§7) compounds this: because every derived artifact is wrapped in an invisible propose→refine→approve contraction, the token spend on any artifact is not a single forward pass but $\kappa$ passes, where $\kappa$ is the mean number of refine iterations to convergence. Ideation and research therefore pay both the per-pass premium of Opus-at-max and the $\kappa$ multiplier of the loop.

We decompose the cost of goods sold for a single venture $v$ into a one-time build component and a recurring live component:

The claim of this volume — quantified in §11.3 — is that $\sum_s C^{\text{tok}}_s$ accounts for roughly $\phi\approx 0.83$ of the fully-loaded build-plus-first-month COGS [illustrative]. Every downstream pricing and margin decision is, to first order, a decision about token spend.

11.2 The frontier token price (cited)

We price against Anthropic's published, current rates. Claude Opus 4.8 — the flagship used for ideation and research at max effort — is billed at $5 per million input tokens and $25 per million output tokens, with cache reads at $0.50/MTok (a 0.1× multiplier on input) and 5-minute cache writes at 1.25× input [Anthropic 2026a]. The Batch API applies a flat 50% discount to both input and output; the 1M-token context window is billed at standard per-token rates with no long-context surcharge [Anthropic 2026a].

Two facts materially shape the model. First, extended-thinking tokens are billed as output tokens at the standard output rate — you pay for the full internal reasoning the model generates, not the summarised trace returned in the response body [Anthropic 2026b]. Running ideation and research at effort: max therefore inflates the output line specifically, which is the expensive one. Second, Opus 4.7-and-later use a newer tokenizer that produces ~30% more tokens for the same text than earlier models [Anthropic 2026a]; all token budgets below are quoted on this new-tokenizer basis, so the inflation is already priced in rather than a hidden surprise.

Source: [Anthropic 2026a]. Server-side web search (used by the research stage) is billed at $10 per 1,000 searches on top of token cost [Anthropic 2026a].

11.3 Per-stage token budgets and the cost formula

For a stage $s$ on a model with input price $p_i$, output price $p_o$, and cache-read price $p_c = 0.1\,p_i$, let $T^{\text{in}}_s$ be input tokens with a cache-hit fraction $\rho_s$, let $\hat T^{\text{out}}_s$ be the model's baseline output, and let $\theta_{e}$ be the multiplier that the effort level $e\in\{\text{low},\text{high},\text{xhigh},\text{max}\}$ applies to output (this is the adaptive-thinking lever). With $w_s$ web searches at p_w=\0.01$each and a batch discount$\beta_s\in{1,,0.5}$:

and the refine loop folds in as $T^{(\cdot)}_s \leftarrow \kappa_s\,T^{(\cdot)}_s$ so that each artifact's spend reflects its convergence path (§7). The build-token total is $\sum_{s}C^{\text{tok}}_s$; the per-token budgets themselves scale with complexity and app-type per §11.5, $\hat T_s = \hat T^{\text{base}}_s\,\mu_{cx}\,\mu_{app}$.

The reference venture — a moderate-complexity web app ($\mu_{cx}=\mu_{app}=1$), with the refine multiplier already folded into the token counts — carries the following budget [illustrative]:

Ideate + research alone are $438 (64%) of token cost, and Opus stages together are 77% — the dominant-line claim, made concrete. Output tokens (the thinking-heavy line) are 56% of token cost, which is why effort and the Fast-mode premium are the levers §11.7 stresses. The build-token subtotal is $639; adding first-month live gives $686 in Anthropic spend [illustrative].

11.4 Non-token COGS

The remaining COGS lines are small but real. Each venture runs in its own per-tenant cell (§4): at idle baseline that is the web tier's floor of 3 pods and the worker tier's floor of 2 (§5's HPA/KEDA bounds), a managed Postgres, an edge-SSR brand worker, and ingress. We model the recurring floor at ~$110/mo [illustrative]; it grows with scale exactly as the $M/M/c$ worker model and HPA targets of §5 predict [Jafarnejad 2019; Gandhi 2012], so the cost curve above the floor is the autoscaler's throughput curve, not a fixed fee. Storage plus egress add ~$20/mo [illustrative]. The one-time Forge CI path (build → Trivy → Cosign → OCI → k3s) amortises to ~$9 per venture in build minutes and registry [illustrative]. Summing against §11.3:

11.5 Complexity × app-type tiers and time-to-build

Token budgets scale multiplicatively along two axes. Complexity captures the depth of the ideation search and the surface area of generated code; app-type captures how many native runtimes the deploy stage must target. Illustrative multipliers [illustrative]:

Cross-platform sits below dual-native because a single RN/Flutter codebase shares most generated modules; twin native targets pay for two code-gen passes. Wall-clock time-to-build is largely automated pipeline time (human gates add calendar latency separately) and scales sub-linearly in app-type because platform targets generate in parallel: $\tau \approx \tau_0\,\mu_{cx}\sqrt{\mu_{app}}$ with $\tau_0\approx 8$ automated hours [illustrative]. Representative cells (build COGS =\648,\mu_{cx}\mu_{app}$; price at an 80% target margin):

All figures [illustrative], built on the cited token rates of §11.2.

11.6 Customer pricing and margin bands

Pricing follows the standard schema: a tiered subscription with bundled monthly credits, per-seat add-ons, usage overages, all billed through Stripe — the same convention the economics volume assumes, kept consistent here so the two volumes compose. We split the offer to match the cost split of §11.4: a one-time build fee covering ideate/research/deploy tokens, and a recurring subscription covering the live cell, seats, and a monthly credit grant sized to the venture's live token budget. For a target margin $m^\star$ in the band $[\underline m,\overline m]=[0.72,\,0.86]$:

Monthly credits map dollars-of-token-budget to a credit unit; consumption beyond the grant is an usage add-on billed at a marked-up effective token rate (protecting margin on the volatile line), and additional editor seats are priced independently of token cost. At $m^\star=0.80$ the reference web/moderate venture is a $3,240 build plus ~$885/mo subscription [illustrative], with the credit grant covering the ~$47/mo live token budget and cell hosting. Higher tiers (Scale, Sovereign) raise the credit grant, the seat ceiling, and the included cell capacity rather than changing the per-token economics.

11.7 Price-sensitivity to the Anthropic token price

Because essentially the entire token line is Anthropic spend, a change in frontier price flows almost directly into COGS. Let $\delta = \Delta p / p$ be the fractional change in the Anthropic token price (input, output, and cache scaling together), and let $\phi$ be the token share of COGS. Holding the customer price $P$ fixed, COGS scales as $\mathrm{COGS}(1+\phi\delta)$, and since $1-m = \mathrm{COGS}/P$, the realised margin moves by

a clean semi-elasticity. With $m=0.80$ and $\phi=0.83$ [illustrative]:

The Fast-mode row is the operational punchline: Opus 4.8 Fast mode is exactly a 2× price step ($10/$50 vs $5/$25) [Anthropic 2026a], and adopting it for the heavy stages would cut the reference margin from 80% to ~63% at a fixed sticker price. That is why the routing policy reserves max-effort standard-mode Opus for ideation/research and never routes them through Fast mode. The symmetric upside is the Pattern-Substrate flywheel (§8): as reusable patterns raise the cache-hit fraction $\rho_s$ and let more offline stages take the 50% Batch discount, the effective frontier price falls ($\delta<0$) and margin expands with no change to the customer price. The defensive levers are therefore explicit and ordered by impact: (1) tune effort so max is spent only where it changes the outcome; (2) route non-frontier stages to Sonnet/Haiku; (3) maximise prompt-cache hits on the large, stable ideation/research context; (4) batch every asynchronous stage.

11.8 A CostModel contract and the quote algorithm

The model above is a pure function of a token schedule and a price book. The interface is small enough to state directly:

TypeScript
55 lines
Copy
type Effort = "low" | "high" | "xhigh" | "max";

interface ModelPrice {         // USD per single token
  input: number; cacheRead: number; output: number;
}
interface StageBudget {
  stage: "ideate" | "research" | "deployArch" | "deployBulk" | "live";
  model: keyof PriceBook;
  effort: Effort;
  inTokens: number; cacheHit: number;   // rho in [0,1]
  baseOutTokens: number; searches: number;
  batch: boolean; refineIters: number;  // kappa
}
type PriceBook = Record<"opus48" | "sonnet5" | "haiku45", ModelPrice>;

interface Quote {
  tokenCost: number; infraCost: number; cogs: number;
  tokenShare: number;                   // phi
  buildPrice: number; subPrice: number; // at target margin
  marginAt: (deltaFrontierPrice: number) => number;
}

const EFFORT_THETA: Record<Effort, number> = {         // [illustrative]
  low: 0.25, high: 1.0, xhigh: 2.0, max: 4.0,
};
const SEARCH_PRICE = 0.01;                              // \$10 / 1,000

function stageCost(b: StageBudget, pb: PriceBook): number {
  const p = pb[b.model];
  const k = b.refineIters;
  const inT = b.inTokens * k, outT = b.baseOutTokens * EFFORT_THETA[b.effort] * k;
  const raw =
      p.input     * (1 - b.cacheHit) * inT
    + p.cacheRead *  b.cacheHit       * inT
    + p.output    *  outT;
  return (b.batch ? 0.5 : 1) * raw + SEARCH_PRICE * b.searches;
}

function quote(
  budget: StageBudget[], infra: number, pb: PriceBook, margin: number,
): Quote {
  const tokenCost = budget.reduce((s, b) => s + stageCost(b, pb), 0);
  const cogs = tokenCost + infra;
  const buildCogs = budget
    .filter(b => b.stage !== "live")
    .reduce((s, b) => s + stageCost(b, pb), 0);
  const liveCogs = cogs - buildCogs;
  return {
    tokenCost, infraCost: infra, cogs, tokenShare: tokenCost / cogs,
    buildPrice: buildCogs / (1 - margin),
    subPrice:  liveCogs  / (1 - margin),
    // Delta m = -(1-m) * phi * delta, applied to the *realised* margin
    marginAt: (delta) => margin - (1 - margin) * (tokenCost / cogs) * delta,
  };
}

The quoting procedure that a sales surface or the deploy broker calls is then a thin wrapper that resolves the tier multipliers before pricing:

Plain Text
15 lines
Copy
Algorithm 11.1  QUOTE(spec, priceBook, marginTarget)
  in:  spec = { complexity, appType, seats }, price book, target margin
  out: a Quote with build price, subscription, and a margin(δ) sensitivity fn
 1  μ_cx  ← COMPLEXITY_MULT[spec.complexity]        # 0.5 .. 3.2
 2  μ_app ← APPTYPE_MULT[spec.appType]              # 1.0 .. 2.4
 3  budget ← clone(BASE_STAGE_BUDGETS)              # §11.3 reference schedule
 4  for each stage b in budget:                     # scale token demand by tier
 5      b.inTokens      ← b.inTokens      × μ_cx × μ_app
 6      b.baseOutTokens ← b.baseOutTokens × μ_cx × μ_app
 7      b.searches      ← b.searches      × μ_app
 8  infra ← CELL_FLOOR + STORAGE + EGRESS           # §11.4, recurring
 9  q ← quote(budget, infra, priceBook, marginTarget)
10  q.subPrice ← q.subPrice + spec.seats × SEAT_PRICE   # per-seat add-on
11  assert q.tokenShare > 0.5      # invariant: frontier tokens dominate COGS
12  return q

Line 11 encodes the thesis as a runtime invariant: if a change to the price book or the token schedule ever drops the token share below half, the economics have stopped being inference-dominated and the pricing model must be revisited. As long as frontier reasoning is the product's marginal cost, the sensitivity function on line returned at step 9 — not the sticker price — is the number that governs the business, and it is pinned directly to a published, verifiable Anthropic rate.

---

12. Novel Patent Portfolio

This volume enumerates the novel, potentially patentable elements of Nexus Axiom as a portfolio of technical disclosures, then drafts one full provisional-style specification for the flagship element. It is an engineering disclosure written for this paper, not legal advice, and asserts no conclusion that any element is patentable — that turns on examination, and the prior-art analysis below is deliberately confined to the academic literature in the paper's verified citation index rather than the patent record, which a filing attorney would search separately. Novelty is claimed at the level of specific combinations of mechanisms grounded in the primitives already specified (see §2, §4, §5, §7, §8), not the individual ingredients (Bradley–Terry, MAP-Elites, HPA/KEDA, graph retrieval), which are cited to source. Numbers marked [illustrative] are not measured. Each entry gives an innovation summary, a core formula where one applies, representative claims in method/system style, and a prior-art differentiation against the verified index.

12.1 Portfolio entries

P1 — Invisible convergent plan-refinement engine with approval as the sole edge into side effects

Innovation. A propose→refine→approve loop (see §7, the Refine Loop) in which an agentic planning engine is fully hidden behind a single branded affordance; the plan is a versioned, structurally-diffable artifact rendered separately from the conversation; and a guarded state machine makes an explicit human approval the only transition that can transmit any step for execution. Propose and refine are pure with respect to the outside world; a plan is inert until ratified.

Core formula. With intent-gap $g$, comparability constants $\alpha\le\beta$, and per-round contraction modulus $L\in[0,1)$, the residual mismatch decays geometrically, so the rounds to reach approval tolerance $\tau$ are bounded:

Representative claims are developed as the full filing in §12.2; the independent method claim recites generating a versioned, non-transmitted plan, refining it against natural-language feedback with a rendered structural diff, and transmitting each latent dispatch only on explicit approval, and the independent system claim recites a guarded state machine whose plan-transmitting state is reachable only from an approval event.

Prior-art differentiation. Iterative self-improvement — Self-Refine [Madaan 2023], Reflexion [Shinn 2023], self-debugging [Chen 2023] — refines autonomously toward a machine objective; P1 refines toward a latent human intent and gates every side effect on a person. Deep-equilibrium and equilibrium-sequence formulations supply the fixed-point framing [Bai 2019, Li 2025] but not a human-gated, invisible planning surface. Mixed-initiative and human-AI guidelines state principles [Horvitz 1999, Amershi 2019] and collaborative-planning work steers agents mid-flight [He 2026, Takerngsaksiri 2024, Chen 2025]; none discloses the combination of a hidden engine, a versioned diffable plan artifact, a contraction-bounded convergence claim, and approval as the sole structural edge into execution.

P2 — Co-evolutionary grounded ideation with adversarial-discounted fitness and a dual survival gate

Innovation. A Catalyst-stage search (see §2, Ideation) that co-evolves a generator and an adversarial-critic population against a grounded evidence set, ranks candidates by a debiased pairwise LLM-judge tournament reconciled to Bradley–Terry strengths, discounts each candidate's immutable-rubric fitness by how effectively live critics defeat it, and emits a quality-diversity archive rather than a single winner.

Core formula. For rubric fitness $f(c)\in[0,1]$, critic severities $\sigma_k$, and grounded defeat-probabilities $p_k(c)$, the effective fitness and the two-part survival gate are

Representative claims.

1. (method, independent) A method comprising: maintaining a candidate population and a critic population; scoring each candidate against a retrieved grounded evidence set with an immutable multi-dimension rubric emitting a keep decision at a fixed threshold; computing an effective fitness by discounting each candidate's rubric fitness by a product over critics of a severity-weighted, grounding-conditioned defeat probability; ranking candidates by a pairwise-preference tournament whose comparisons are scored in both orderings and admitted only when order-consistent; and admitting a candidate to a quality-diversity archive keyed by a behavior descriptor only when it satisfies both the keep decision and an adversarial-survival floor.
2. (dependent) The method of claim 1, wherein a single mutation operator evolves both populations, differing only by an objective to raise grounded fitness or to defeat surviving candidates, and wherein retrieval queries for a subsequent round are derived from a weaknesses field returned by the rubric.
3. (dependent) The method of claim 1, further comprising maintaining online per-candidate ratings updated per comparison and periodically re-fitting latent strengths by a minorization–maximization iteration over the comparison graph, the online expected score equalling the Bradley–Terry win probability.

Prior-art differentiation. LLM-as-judge ranking evaluates existing outputs [Zheng 2023, Chiang 2024, Liu 2023] with known position/verbosity/self-enhancement biases [Wang 2023, Dubois 2024]; P2 folds debiasing into the schedule and drives generation. Open-ended co-evolution [Wang 2019, Bansal 2017, Openendedlearningteam 2021, Hughes 2024] and QDAIF [Bradley 2023] operate over environments/agents or free-form artifacts; P2's novelty is grounded venture-hypothesis co-evolution with an immutable-rubric gate and an adversarial-discounted floor, over a MAP-Elites archive [Mouret 2015] ranked by Bradley–Terry/Elo [Bradley 1952, Elo 1978, Hunter 2004, Boubdir 2024].

P3 — Automated sovereign white-label cell with zero-reveal edge brand assertion and a read-only federation edge

Innovation. A deterministic, idempotent provisioning sequence (see §4, Deploy) that stands up a per-venture sovereign cell satisfying seven independence criteria, resolves the venture's brand at the edge during server-side rendering so no first-party string is reachable at first paint (the guarantee is scoped to first paint; later network- and timing-based side-channels are out of scope), verifies zero-reveal as a hard provisioning gate, and connects the cell to a shared cognitive plane through a federation edge strictly read-only from the venture side.

Core formula. Worker autoscale is set analytically from an $M/M/c$ offered-load solve, then tracked reactively by the queue controller: with offered load $a=\lambda/\mu$ and SLO wait $W_q^{\text{SLO}}$, choose minimal $c^\star>a$ meeting the SLO and set the per-replica target

Representative claims.

1. (method, independent) A method for provisioning an isolated tenant deployment comprising: creating for a venture a dedicated namespace, source repository, isolated database, identity realm, custom domain, and continuous-delivery pipeline; configuring an edge server-side renderer to resolve a brand descriptor from an inbound host header and emit a themed shell before a first byte of markup; asserting, as a precondition to advancing the pipeline to rollout, that a first paint contains no first-party identifier; and registering a federation edge to a shared control plane that is read-only from the venture side.
2. (dependent) The method of claim 1, wherein a worker autoscaler's per-replica queue-depth target is computed from an offered-load model such that a reactive equilibrium reproduces a minimal worker count meeting a job-completion latency objective.
3. (dependent) The method of claim 1, wherein deployment artifacts are composed from generalized, interface-level patterns behind an isolation firewall and never from verbatim cross-tenant source, and rollback is effected by reverting a repository tag and redeploying a previously signed image.

Prior-art differentiation. The multi-tenancy literature maps a silo/pool/bridge isolation spectrum [Chong 2006, Ochei 2018, Kumar 2026] and enforces performance isolation on shared stores [Shue 2012, Zheng 2021, Mckeown 2008]; autoscaling [Ahmad 2024, Pilyai 2023, Ramperez 2021] and queueing-based provisioning [Jafarnejad 2019, Urgaonkar 2008, Gandhi 2012] are well studied. P3's novelty is the combination: fully automated per-venture silo provisioning with an edge-SSR zero-reveal brand assertion elevated to a build-blocking gate, a read-only federation edge to a shared brain, and a queue set-point derived analytically then tracked reactively.

P4 — Pattern-learning substrate with a generalized-pattern IP firewall and an output-side reproduction gate

Innovation. A retrieval-only, graph-structured memory (see §8, the Pattern Substrate) that indexes only generalized patterns — structure, roles, dependency edges, with literals, secrets, and identity stripped — admits a pattern to a shared index only under cross-tenant support or recorded consent, deduplicates to reward generality over repetition, and runs a deterministic, generator-independent reproduction gate on every emitted artifact that treats any cross-tenant contiguous match as an unconditional failure.

Core formula. With generalization operator $g:a\mapsto p$, distinct-tenant support $\sigma(p)\ge k$ for admission, and a normalized longest-contiguous-overlap reproduction score, emission requires

Representative claims.

1. (method, independent) A method comprising: abstracting artifacts of a consented source repository into generalized patterns retaining component roles, interface shapes, and dependency edges while stripping literals, secrets, and identifying strings; admitting a pattern to a shared index only when a count of distinct contributing tenants meets a threshold or a recorded consent and a reproduction-safety check are satisfied, and persisting no source-tenant identity on the admitted pattern; retrieving generalized patterns to condition a generative model; and, before emitting the generated artifact, rejecting it if a normalized longest-contiguous-token-overlap against a check-only source corpus exceeds a threshold, wherein any nonzero overlap against a source of a different tenant is an unconditional rejection.
2. (dependent) The method of claim 1, wherein the shared index contains no raw source and exposes no raw-retrieval path, such that model weights are never trained on tenant source and the retrieval channel carries only abstractions.
3. (dependent) The method of claim 1, wherein near-duplicate patterns are collapsed to a canonical node whose retrieval salience is a function of distinct-tenant support rather than duplicate multiplicity, and the method is fail-closed — dropping or escalating on absent consent, identifiable residue, or a reproduction hit — regenerating once under a stronger abstraction instruction before escalating to a human waypoint.

Prior-art differentiation. The memorization literature establishes that training exposes verbatim extraction and that duplication is its strongest predictor [Carlini 2019, Carlini 2021, Carlini 2023, Nasr 2023, Kandpal 2022, Karamolegkou 2023]; P4 closes the tenant-source training channel by construction (the substrate never trains on or fine-tunes over tenant source) and bounds the retrieval channel with generalization, $k$-support admission, deduplication, and an asymmetric reproduction gate; base-model pretraining memorization is narrowed but not closed by this construction (see §14). Graph-RAG [Edge 2024, He 2024, Sun 2024, Gutierrez 2024, Guo 2024] and pooled multi-tenant RAG [Kumar 2026] share an index of data; P4 shares only abstractions that belong to no one.

P5 — Governed generative-UI dispatch: every agent-rendered action mediated by a single ordered multi-gate broker

Innovation. An interaction architecture (see §4, Deploy) in which the agent renders live UI components into an artifact pane (AG-UI), yet no rendered control acts on its own authority: every action — an inspector-card button, an agent-rendered form, a chat instruction — is funneled through one dispatch entrypoint that runs an ordered, total sequence of pre-execution gates and hands accepted work to a single executor, surfacing a legible denial reason to the user.

Core formula. Let $d$ be a dispatch and $\gamma_1,\dots,\gamma_5$ the ordered gates (classification, data-residency, export-class, spend, safety). The external effect of any rendered control is empty unless every gate admits:

Representative claims.

1. (method, independent) A method comprising: streaming, from a generative agent, typed events that a renderer converts into interactive user-interface components in a surface; and, responsive to activation of any said component, routing a corresponding action through a single dispatch entrypoint that evaluates an ordered plurality of pre-execution gates and enqueues the action to a single executor only when every gate admits, such that the component's rendering confers no authority to act and a denial returns a machine-legible reason for display.
2. (dependent) The method of claim 1, wherein the gates are evaluated in the order classification, data-residency, export-class, spend, then safety; each action carries a correlation identifier mirrored to a progress dock and to the generative-UI event stream; and a declarative inspector card of an action kind dispatches through said entrypoint rather than acting locally, a card with a missing value rendering an absence indicator rather than a fabricated value.
3. (system, independent) A system wherein the dispatch entrypoint and the executor are each singular, so that exactly one governance path exists and no client can bypass the gates.

Prior-art differentiation. Tool-use and generative-UI systems let a model decide when and which tool to invoke and render results [Schick 2023, Yao 2023, Patil 2023, Qin 2024, Yang 2024, Si 2024]; there the invoked tool acts on its own authority. P5's novelty is decoupling proposal from authority: the agent may render any control, but the control's effect factors through one ordered total-gate broker and one executor, making governance structural rather than advisory.

P6 — Re-enterable versioned pivot over a content-addressed venture-artifact graph

Innovation. Venture state is a directed acyclic graph of content-hashed artifacts with derivation edges (see §5, Live); a pivot is an edit whose consequences are exactly the stale cone of influence — the edited artifacts and their transitive dependents — re-derived through the same per-artifact gated engines, presented as an artifact-level diff, and cut over only on approval, rollback reduced to reverting a tag.

Core formula. For an edit $\Delta$ and derivation reachability $\rightsquigarrow$, only the cone is recomputed; a version is a Merkle root over reachable artifacts:

Representative claims.

1. (method, independent) A method comprising: representing a deployed venture as a graph of content-hashed artifacts with derivation edges; responsive to an edit designating one or more artifacts, computing a stale cone comprising the designated artifacts and their transitive dependents; re-deriving each artifact of the cone in derivation order through an owning engine wrapped in a human-gated refinement loop; presenting an artifact-level diff against the live version; and cutting over to a new tagged version only responsive to approval, the live tag remaining unmutated until cutover, artifacts outside the cone being carried forward unchanged.
2. (dependent) The method of claim 1, wherein rollback comprises repointing a live pointer to a prior tagged version and redeploying its previously signed image without re-derivation.
3. (dependent) The method of claim 1, further comprising carrying two candidate versions sharing a parent and routing a fraction of traffic to a canary tag before cutover.

Prior-art differentiation. Human-in-the-loop software agents surface intermediate artifacts for correction [Takerngsaksiri 2024, He 2026, Chen 2025]; P6's novelty is applying build-system-style incremental recomputation — a minimal dependency cone over a content-addressed graph — to gated venture state, with per-artifact human approval along a topological order and revert-as-rollback backed by signed images.

12.2 Full provisional-style specification — P1 (Refine Loop)

The following is a provisional-style disclosure for the flagship element. It is illustrative and not legal advice; claim scope and patentability would be determined on examination.

Title. System and method for human-gated, convergent plan refinement in which an explicit approval is the sole structural edge into external side effects.

Field. The disclosure relates to human-AI interaction and agentic planning systems, and more particularly to interfaces that mediate between a natural-language planning engine and side-effecting execution through a governed, versioned, human-ratified plan.

Background. Agentic systems increasingly generate multi-step plans and act on them. Autonomous refinement methods improve a plan against a machine-defined objective and then execute [Madaan 2023, Shinn 2023, Chen 2023], but neither target a latent human intent nor interpose a structural approval before external effects. Mixed-initiative and human-AI principles [Horvitz 1999, Amershi 2019] and collaborative-planning studies [He 2026, Takerngsaksiri 2024, Chen 2025] argue for human steering yet do not disclose a mechanism in which (a) the planning engine is invisible, (b) the plan is a versioned, structurally-diffable artifact rendered apart from the conversation, (c) approval is the only transition that transmits a step for execution, and (d) convergence is characterized so refinement dialogues are provably short. A need exists for a planning surface that lets a non-technical user argue with a legible proposal while nothing irreversible occurs without consent.

Summary. Embodiments provide a method and system in which a planning engine generates a versioned plan of an intent digest, an ordered plurality of steps each encoding a latent dispatch request that is drawn but not fired, and a rationale. The plan is rendered into an artifact surface; natural-language feedback drives a refinement operator producing a successor plan of incremented revision, with a structured diff rendered in place. Only an explicit approval transmits each latent dispatch to a single governed entrypoint that evaluates an ordered plurality of pre-execution gates before enqueuing to a single executor. Because generation and refinement never transmit, and transmission is reachable only through the approval branch, the safety property is a shape of the program rather than a convention. Under a contraction assumption the intent-gap decays geometrically, bounding the rounds to approval.

Brief description of the drawings.

• FIG. 1 — block diagram: conversational interface, artifact surface, planning engine (a common propose/refine operator), diff engine, guarded state machine, governed multi-gate dispatch entrypoint, and single executor.
• FIG. 2 — flowchart of the propose→refine→approve state machine, showing the approval branch as the sole transition into a transmitting state and the abort/refine branches as side-effect-free.
• FIG. 3 — the versioned plan data structure: monotone revisions; steps each carrying a latent dispatch and a reversibility flag; a diff carrying typed step-changes and a scalar gap-delta.
• FIG. 4 — a plot [illustrative] of the intent-gap decaying geometrically across refine rounds toward an approval-tolerance line.
• FIG. 5 — a schematic of a multi-stage pipeline, each stage wrapped by the loop, converting multiplicative intent-drift into bounded additive drift.

Detailed description. With reference to FIG. 1–2, a stage seed $s$ is received at the conversational interface. The planning engine computes $p_0=\mathrm{Propose}(s)$; a fresh plan is the empty-feedback case of the same operator that later refines, so the interface exposes one verb. The guarded state machine renders $p_0$ and awaits $a\in\{\text{approve},\text{refine}(f),\text{abort}\}$. On $\text{refine}(f)$ the engine computes $p'=T(p,f)$ and the diff engine computes $\mathrm{Diff}(p,p')$ carrying a gap-delta estimated by a preference-scoring model [Liu 2023] that drives display only and is excluded from the transmit condition. On approve — and only then — each step's latent dispatch is transmitted to the governed entrypoint, which evaluates gates in order (classification, data-residency, export-class, spend, safety) and enqueues accepted work to the sole executor. On abort or on reaching a maximum round count $K$, the loop terminates without external effect, optionally emitting a scope-reduction suggestion.

Plain Text
13 lines
Copy
Algorithm P1  GuardedRefine
Input: seed s, max rounds K
 1  p ← Propose(s); render(p); k ← 0
 2  loop:
 3    a ← awaitAction()                 # approve | refine(f) | abort
 4    if a = approve:                    # THE ONLY EDGE INTO SIDE EFFECTS
 5        for step in p.steps: dispatch(step) → governed entrypoint
 6        return p
 7    if a = abort: return ABORT
 8    if a = refine(f):
 9        p' ← T(p, f); render(Diff(p, p'))            # still inert
10        p ← p'; k ← k + 1
11        if k ≥ K: summarize(p); suggest scope-cut

The refine and diff paths never invoke the dispatch call, so a static reader verifies by inspection that no plan reaches the executor without traversing the approve branch (an executed flag is true on exactly that branch; see the refineStep contract in §7, the Refine Loop). In embodiments the loop re-arms on a computed stale cone of influence for a pivot (see §5/P6) and wraps each of a plurality of ordered stages, converting per-stage fidelity loss from a multiplicative product into a bounded additive sum $\Phi\ge 1-\sum_i\varepsilon_i$.

Claims.

1. A computer-implemented method comprising: generating, by a planning engine and without producing a side effect external to the method, a versioned plan comprising an intent digest, an ordered plurality of steps each encoding a latent dispatch request that is not transmitted, and a rationale; rendering the plan into an artifact surface distinct from a conversational interface; responsive to natural-language feedback received at the conversational interface, applying a refinement operator to produce a successor plan of incremented revision and rendering a structured diff between the plan and the successor plan; and transmitting each said latent dispatch request to a governed dispatch entrypoint for execution only responsive to an explicit approval input, whereby no said step produces a side effect external to the method absent the approval input.
2. The method of claim 1, wherein the generating and the refinement operator are performed by a common engine invoked with different priors, a freshly generated plan being an empty-feedback case of the refinement operator, and neither the refinement operator nor computing the structured diff invokes the governed dispatch entrypoint.
3. The method of claim 1, wherein the structured diff comprises typed step-changes selected from add, remove, modify, and reorder, and a scalar gap-delta estimating a change in an intent-gap between the successor plan and a latent user intent, the gap-delta driving a display and being excluded from a condition governing said transmitting.
4. The method of claim 1, wherein said transmitting routes each latent dispatch request through an ordered plurality of pre-execution gates comprising classification, data-residency, export-class, spend, and safety gates, and enqueues an admitted request to a single executor.
5. The method of claim 1, wherein the refinement operator is configured such that a successive intent-gap decays by at least a constant factor per iteration, bounding a number of iterations to reach an approval tolerance, and the iterating is bounded by a maximum round count beyond which the method emits a scope-reduction suggestion without producing said external side effect.
6. The method of claim 1, wherein the plan and successor plan are pure with respect to external state in that no customer data is read or written, no budget is spent, and no compute resource is provisioned prior to the approval input.
7. A system comprising one or more processors and a memory storing instructions that, when executed, cause the system to implement a guarded state machine having a plan-transmitting state reachable only from an approval event, and to perform the method of claim 1; and wherein venture state is optionally represented as a graph of content-hashed artifacts and the method re-arms on a computed cone of transitive dependents of an edited artifact.
8. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause performance of the method of claim 1.

12.3 Portfolio posture

The six elements are complementary rather than overlapping: P1 governs when action is permitted, P5 how each action is mediated, P3 where it runs, P4 what may be reused across tenants, P2 what is proposed, and P6 how it changes over time. Filed as a family they read as one coherent claim to a human-gated, tenant-isolated, self-grounding venture-building architecture. This is a disclosure for the paper, not a legal opinion; a practitioner would conduct a full prior-art search — including the patent record, outside this paper's academic index — before any filing.

---

13. UI/UX & Experience Compendium

This volume is the paper's visual inventory. Where §4 specified the interaction architecture — unified chat, AG-UI artifacts, PCC, the inspector's declarative k-cards — and §6 derived the design psychology, this compendium enumerates every surface a human ever sees, gives it a place in a taxonomy, and fixes the two drawing conventions the paper uses to depict surfaces without ambiguity. It is deliberately catalogue-like. The claims live elsewhere; here we make the surface set legible and countable, so that an engineering team can read the paper and know exactly which screens exist, which frame each reuses, and how any one of them is reached. Two invariants hold across the entire inventory: every surface renders in the research-derived, not-dark design system (see §6), and the Adverant backend is never a surface — it is a sealed black box that no screen, header, or bundle reveals (see §4.1).

13.1 Two drawing conventions

A compendium of ~200 mockups is only useful if its figures are stable under copy, diff, and print. We therefore adopt an ASCII-first, low-fidelity discipline: the archetypes are wireframes, not renders, and the low-fidelity prototyping tradition is explicit that this is a feature — cheaper to produce, faster to compare across concepts, and a better communication device than a pixel-perfect mock that invites bikeshedding over color instead of structure [Rudd 1996]. Fidelity is supplied later, once, by the design system (§6); the archetype only fixes layout and information architecture. Two conventions divide the labor.

Strict-ASCII archetype frames. The 15 reusable screen archetypes are drawn using only the printable ASCII set — + - | = [ ] < > and text. No box-drawing glyphs. A strict-ASCII frame renders identically in a terminal, a code review, a .tex verbatim block, and a plain-text export, and it produces clean line-diffs when a layout is revised. This is the grammar for anything that is a screen.

Unicode flow/atlas grammar. Topology — user flows, customer journeys, and the architecture atlas — needs direction and nesting that ASCII cannot express economically. For these we use box-drawing and arrow glyphs (─ │ ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼ → ↓ ●). This is the grammar for how screens connect, never for the screens themselves.

Both conventions obey one hard rule: no line exceeds 110 columns, so every figure fits an A4/Letter text block without reflow. The convention is chosen by what is drawn, not by preference — screen ⇒ strict-ASCII; topology ⇒ Unicode.

TypeScript
15 lines
Copy
// Surface inventory contract (illustrative, interface-level).
type SurfaceClass = "marketing" | "console";
type Archetype =
  | "chat-artifact" | "inspector-split" | "pcc-dock" | "refine-review"
  | "hero" | "feature-grid" | "pricing" | "wizard" | "table" | "dashboard"
  | "form-in-pane" | "settings" | "auth" | "empty-state" | "gate-modal";

interface SurfaceDescriptor {
  id: string;
  cls: SurfaceClass;
  archetype: Archetype;      // one of the 15 frames
  stage?: "catalyst" | "thesis" | "crucible" | "apex";  // console only
  theme: "vd-not-dark";      // always the research-derived system (§6)
  backendVisible: false;     // structural invariant: never true
}

13.2 The surface taxonomy

The inventory splits at authentication. Marketing surfaces are public, pre-auth, and follow the NexusROS section pattern — a vertical composition of hero, proof, feature grid, pricing, and call-to-action bands. Console surfaces are the product itself, post-auth, organized around one primary surface and four supporting ones, all four of the pipeline stages (Catalyst, Thesis, Crucible, Apex; see §2–§5) expressed as states of the same primary frame rather than as distinct applications.

The 15 archetypes are the closed vocabulary: chat-artifact, inspector-split, pcc-dock, refine-review, hero, feature-grid, pricing, wizard, table, dashboard, form-in-pane, settings, auth, empty-state, gate-modal. Every one of the ~200 gallery mockups is an instance of exactly one archetype in exactly one theme. The rest of this volume draws curated exemplars; the complete gallery is inserted at assembly.

13.3 The primary surface — full-screen chat + AG-UI artifact pane

Everything the customer does happens here. Chat proposes; the artifact pane renders; nothing on either side acts except through UNO (see §4.4).

Plain Text
17 lines
Copy
+==============================================================================+
|  [brand]  Acme Bakery                              [PCC .]  [acct v]  [help] |
+---------------------------------+--------------------------------------------+
|  UNIFIED CHAT                    |  ARTIFACT PANE  (AG-UI)                    |
|  channel: assistant  mode: chat  |  [ Launch Plan ]  [ Storefront ]  [ + ]   |
|---------------------------------|--------------------------------------------|
|  you>  add online ordering       |  +--------------------------------------+  |
|                                  |  |  LAUNCH PLAN  (proposed)   rev 3     |  |
|  nexus>  here is the plan --->   |  |  1. Menu schema       [ ok ]         |  |
|          review it in the pane   |  |  2. Cart + checkout   [ ok ]         |  |
|                                  |  |  3. Stripe payments   [ needs key ]  |  |
|  you>  make delivery optional    |  |  4. Delivery (opt.)   [ added ]      |  |
|                                  |  +--------------------------------------+  |
|  [ type a message .............] |     [ Review & Refine ]   [ Approve ]     |
+---------------------------------+--------------------------------------------+
|  transport: socket.io (sse fallback)   session #a91f   * backend: sealed     |
+==============================================================================+

The dock chrome ([PCC .]), the channel/mode indicators, and the transport line are direct reflections of the UnifiedChatSurface model (§4). "backend: sealed" is not decoration — it is the visible restatement of the black-box invariant.

13.4 One surface per stage

Each stage is the same chat-artifact frame with a different artifact loaded and a different gate on the button. Drawn compactly:

Plain Text
17 lines
Copy
CATALYST (Ideate)                        THESIS (Research)
+----------------------------------+     +----------------------------------+
| chat | ARTIFACT: Idea Arena      |     | chat | ARTIFACT: Cited Dossier   |
|      | A vs B  ELO 1543 / 1490   |     |      | Claim 1 .......... [3 src]|
|      | C vs A  Red Queen critic  |     |      | Claim 2 .......... [5 src]|
|      | keep >= 60  (5-dim eval)  |     |      | TAM  ............. [ -- ] |
| [ Refine ]      [ Pick Winner ]  |     | [ Refine ]     [ Accept Thesis ] |
+----------------------------------+     +----------------------------------+

CRUCIBLE (Deploy)                        APEX (Live)
+----------------------------------+     +----------------------------------+
| chat | ARTIFACT: Deploy Diff     |     | chat | ARTIFACT: Ops + Pivot     |
|      | + cell-ns  + db  + oauth  |     |      | HPA web 3->15  err 0.2%  |
|      | brand preview  [themed]   |     |      | remediation: restart wkr |
|      | build->trivy->cosign  ok  |     |      | pivot: edit hero copy    |
| [ Refine ]        [ Approve ]    |     | [ Refine ]   [ Approve pivot ]   |
+----------------------------------+     +----------------------------------+

The [ -- ] in the Thesis dossier is the k-card missing-value em-dash (rendered here in ASCII as --): TAM is unknown, so it is shown as absent, never fabricated (see §4.5). The four buttons — Pick Winner, Accept Thesis, Approve, Approve pivot — are all the same edge into execution: an explicit approval that dispatches through UNO's five gates.

13.5 The Refine-Loop surface

The flagship surface (see §7, the Refine Loop) is a specialization of chat-artifact in which the artifact is a ProposedPlan and a visible diff animates each refinement over the prior revision.

Plain Text
14 lines
Copy
+==============================================================================+
|  REVIEW & REFINE          plan rev 4  (was rev 3)        intent-gap: closing |
+------------------------------------------------------------------------------+
|  INTENT DIGEST:  "Irish-market-first bakery storefront, no loyalty program"  |
|------------------------------------------------------------------------------|
|   1. Menu schema (EUR, VAT 13.5%)                          [ modified ]      |
|   2. Cart + checkout                                       [ unchanged ]     |
|   3. Loyalty points                                        [ REMOVED  ]      |
|   4. Hosting: eu-west (Dublin)                             [ added    ]      |
|------------------------------------------------------------------------------|
|  you>  "make it Irish-market first, drop loyalty, cheaper hosting"           |
|                                                                              |
|         [ Refine again ]                             [ Approve plan ]        |
+==============================================================================+

Steps are drawn, not fired. Only Approve plan crosses from artifact into action, and it does so as an ordinary dispatch. The diff badges (modified / removed / added / unchanged) are the surface rendering of the refinement operator's output — the user watches their words become structure, which is exactly the visibility that makes such planners trustworthy [Amershi 2019].

13.6 A marketing home (NexusROS section pattern)

Plain Text
16 lines
Copy
+==============================================================================+
|  [brand]                         product   pricing   docs        [ sign in ] |
+------------------------------------------------------------------------------+
|                                                                              |
|            From a sentence to a live company.                                |
|            Describe the venture. Approve the plan. Watch it ship.            |
|                                                                              |
|                        [ Start building ]   [ See a demo ]                   |
+------------------------------------------------------------------------------+
|  [ Ideate ]        [ Research ]        [ Deploy ]        [ Go live ]         |
|  co-evolutionary   cited dossiers      sovereign cell    self-healing, gated |
+------------------------------------------------------------------------------+
|  "One approval at every gate. Nothing irreversible happens unattended."      |
+------------------------------------------------------------------------------+
|            [ Pricing: tiered + credits + per-seat + usage ]                  |
+==============================================================================+

The four bands map one-to-one to the pipeline stages, and the pricing band states the schema convention (tiered subscription + monthly credits + per-seat + usage add-ons) without numbers, which belong to §10/§11.

13.7 Flows and journeys (Unicode grammar)

An end-to-end user flow traces the happy path across stages; each ◇ is a human gate — an approval — and never an autonomous jump.

Plain Text
15 lines
Copy
┌─────────┐   ┌──────────┐   ┌───────────┐   ┌──────────┐   ┌──────────┐
│ sign in │ → │ describe │ → │  CATALYST │ → │  THESIS  │ → │ CRUCIBLE │
└─────────┘   │  venture │   │  ideate   │   │ research │   │  deploy  │
              └──────────┘   └─────┬─────┘   └────┬─────┘   └────┬─────┘
                                   │ ◇ pick        │ ◇ accept     │ ◇ approve
                                   ↓ winner        ↓ thesis       ↓ deploy
                             (refine loop)   (refine loop)   (refine loop)
                                                                  │
                     ┌──────────┐        ┌───────────────┐        ↓
                     │   APEX   │ ←──────│ edge-SSR brand │ ← cell live
                     │  live +  │        │ (first paint)  │
                     │  pivot ◇ │        └───────────────┘
                     └────┬─────┘
                          │ re-entry (versioned pivot, see §5)
                          └──────────────► back to the relevant gate only

A customer-journey map overlays the same path with the operator's emotional and cognitive state, the surface in view, and the trust signal each stage must deliver:

Plain Text
8 lines
Copy
stage    │ CATALYST     │ THESIS       │ CRUCIBLE     │ APEX
─────────┼──────────────┼──────────────┼──────────────┼──────────────────
doing    │ argue ideas  │ read sources │ preview brand│ watch it run
feeling  │ curious      │ skeptical    │ anxious      │ in-control
surface  │ idea arena   │ cited dossier│ deploy diff  │ ops + pivot
trust    │ ELO is fair  │ every claim  │ nothing ships│ remediations are
signal   │ & legible    │ has a source │ unapproved   │ gated by blast-radius
gate     │ ◇ pick       │ ◇ accept     │ ◇ approve    │ ◇ approve pivot

The journey is intentionally monotone in trust: skepticism at Thesis is answered by per-claim citations; anxiety at Crucible is answered by an unshippable-until-approved diff and a themed first-paint preview.

13.8 App-only architecture atlas (tenant cell + sealed backend)

The atlas depicts only what a venture is — its sovereign cell — and draws the Adverant brain as an opaque box reachable across a strictly read-only federation edge (see §4.1).

Plain Text
21 lines
Copy
                       user ──► https://acme.example  (custom domain, TLS)
                                        │
                              ┌─────────▼──────────┐
                              │  EDGE (SSR brand)  │  first paint = venture brand
                              └─────────┬──────────┘
   ┌──────────────────────────── SOVEREIGN CELL (own k8s namespace) ───────────┐
   │   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌───────────────────────┐  │
   │   │ web pods │   │ workers  │   │ own DB   │   │ own OAuth realm       │  │
   │   │ HPA 3–15 │   │ KEDA 2–10│   │ (private)│   │ + own forge repo/CI   │  │
   │   └────┬─────┘   └────┬─────┘   └──────────┘   └───────────────────────┘  │
   │        │   POST /api/v1/dispatch   │                                      │
   │        └──────────┬────────────────┘                                      │
   └───────────────────┼───────────────────────────────────────────────────────┘
                       │  federation edge  (read-only from cell → brain)
                       ▼
        ╔══════════════════════════════════════════════════╗
        ║   ADVERANT BRAIN  —  SEALED BLACK BOX             ║
        ║   UNO 5-gate broker · nexus-workflows executor    ║
        ║   CMA / GraphRAG · Pattern Substrate (see §8)     ║
        ║   (no venture code or tenant data crosses back)   ║
        ╚══════════════════════════════════════════════════╝

The double-ruled box is a convention of this volume: any double-ruled region is off-limits to depiction — we draw its interface (/api/v1/dispatch) and its guarantees, never its internals.

13.9 The thirty use cases

The compendium instantiates the full surface set for thirty representative ventures, so that the archetypes are exercised across genuinely different domains rather than one flattering example. Each use case renders all applicable surfaces — marketing home through Apex ops — in §6, with the same governed spine.

1 bakery storefront · 2 boutique fitness studio · 3 indie SaaS analytics · 4 legal-intake portal · 5 medical-clinic booking · 6 real-estate listings · 7 online course platform · 8 restaurant reservations · 9 freelance marketplace · 10 nonprofit donations · 11 event ticketing · 12 subscription box · 13 B2B lead-gen site · 14 podcast membership · 15 property management · 16 dental practice · 17 boutique hotel · 18 artisan e-commerce · 19 fintech budgeting app · 20 HR onboarding tool · 21 community forum · 22 job board · 23 recruiting CRM · 24 field-service dispatch · 25 veterinary clinic · 26 coworking-space booking · 27 insurance quote portal · 28 travel-itinerary planner · 29 creator storefront · 30 local-services directory.

Across all thirty, the archetype count is constant (15) and the stage progression is identical; only the content rendered into the artifact pane and inspector differs. That constancy is the point of the taxonomy: heterogeneous ventures, one governed conversation, one design system, one sealed backend. The complete visual gallery — every surface for every use case — follows.

Appendix B — Full Mockup Gallery (every surface + all 30 use cases)

Built in batches: B.1 Marketing (16) · B.2 Console (36) · B.3 Archetypes (15) · B.4 User-flows (15) · B.5 Journeys (5) · B.6 Architecture (14) · B.7 Use cases (30 × full surface set). (This section grows across turns until complete.)

B.1 Marketing surfaces (MK-01 … MK-16)

MK-01 · Home

+==================================================================================================+
| NEXUS AXIOM      Product  Method  Use cases  Pricing  Research  Docs      [ Start Building ▸ ]   |
+==================================================================================================+
|                F R O M   H Y P O T H E S I S   T O   H Y P E R - S C A L E .                       |
|           Ideate ▸ research ▸ deploy ▸ live — the AI venture builder. Piloted by you.              |
|                    [ Start Building ▸ ]      [ Watch a 2-min build ]                               |
|           +-----------------------------------------------------------------+                     |
|           |  live product shot: full-screen chat + AG-UI artifact canvas    |                     |
|           +-----------------------------------------------------------------+                     |
+--------------------------------------------------------------------------------------------------+
| TRUST     grounded in arXiv · zero-hallucination · sovereign white-label · you own the repo       |
| PROBLEM   "You have the idea. Between it and a live product: 9 months and \$250k."                 |
| SOLUTION  Four gated stages —  The Catalyst · The Thesis · The Crucible · The Apex               |
| FEATURES  [grounded research] [sovereign deploy] [full-screen chat] [live gating] [own repo]      |
| STATS     12-source theses · 1-day deploys · 7/7 sovereignty · HPA 3→15                            |
| HOW       Describe ▸ Approve thesis ▸ Approve deploy ▸ Go live (re-enter anytime)                 |
| JOURNEYS  founder · agency · intrapreneur (before→after)                                          |
| PRICING   Starter · Builder · Studio · Enterprise            FAQ · CTA                             |
| FOOTER    Product · Method · Pricing · Research · Docs · Privacy · Terms       © Adverant          |
+==================================================================================================+

MK-02 · Method (the 4 gated stages)

+==================================================================================================+
| NEXUS AXIOM      Product  Method  Use cases  Pricing  Research  Docs      [ Start Building ▸ ]   |
+==================================================================================================+
|  H O W   N E X U S   A X I O M   B U I L D S                                                       |
|  One idea in. A live, sovereign, versioned product out. You gate every step.                      |
+--------------------------------------------------------------------------------------------------+
|  01  THE CATALYST · Ideate     ELO + Red-Queen tournament over grounded candidates  ── gate ──►   |
|  02  THE THESIS · Research      12-source arXiv/market/mobile thesis (Claude Opus)   ── gate ──►   |
|  03  THE CRUCIBLE · Deploy      sovereign white-label cell, own domain, HPA scaling  ── gate ──►   |
|  04  THE APEX · Live            self-healing product; re-enter/pivot anytime; you own the repo     |
+--------------------------------------------------------------------------------------------------+
|  [ diagram: re-entry loop — any stage, incl. editing a deployed site ]                            |
|  CTA   [ Start Building ▸ ]                                                                        |
+==================================================================================================+

MK-03 · Product / Features

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  E V E R Y T H I N G   Y O U   N E E D   T O   S H I P                                             |
+--------------------------------------------------------------------------------------------------+
|  #grounded-research   Deep arXiv/market/mobile thesis, zero hallucination, every claim sourced    |
|  #full-screen-chat    Chat spine + AG-UI artifact canvas (MCP-driven), chat at every step         |
|  #sovereign-deploy    Own repo · ns · DB · OAuth · domain · TLS — zero Adverant reveal            |
|  #horizontal-scale    HPA 3→15 + KEDA queue scaling, built for load on day one                    |
|  #live-gating         You approve every commit; nothing ships unattended                          |
|  #versioned-pivot     Re-enter any stage; edit a deployed site; git revert anytime                |
|  #artifact-library    Papers · GTM · patents · mockups · PID · docs — all generated               |
|  [ See it build (demo) ]        [ Start Building ▸ ]                                               |
+==================================================================================================+

MK-04 · Full-screen-chat product tour

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  T H E   C A N V A S :   C H A T   +   L I V E   A R T I F A C T S                                 |
|  Watch the agent stream real UI into the artifact pane as you talk.                               |
+--------------------------------------------------------------------------------------------------+
|   +-- chat -----------+  +-- artifact (AG-UI, MCP-driven) -----------------------------------+    |
|   | you: "add tiers"  |  |  [ Thesis ][ Pricing ][ Mockup ][ Code ]                          |    |
|   | axiom: streaming… |  |  live-rendered pricing table appears as you speak                 |    |
|   +-------------------+  +-------------------------------------------------------------------+    |
|  Beautiful, readable rendering · inspector + k-cards on select · PCC shows every job               |
|  CTA  [ Start Building ▸ ]                                                                         |
+==================================================================================================+

MK-05 · Pricing

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  P R I C I N G          [ monthly | annual  save 20% ]                                             |
+---------------------+---------------------+---------------------+------------------------------+
|  STARTER            |  BUILDER  (popular) |  STUDIO             |  ENTERPRISE                  |
|  $X /mo             |  $XX /mo            |  $XXX /mo           |  Contact sales               |
|  1 venture          |  5 ventures         |  unlimited ventures |  white-label + SSO + SLA     |
|  research credits   |  + deploy cells     |  + NexusROS GTM 90d |  + dedicated cells           |
|  own repo           |  own repos          |  priority research  |  procurement / DPA           |
|  [ Start ]          |  [ Start ]          |  [ Start ]          |  [ Talk to us ]              |
+---------------------+---------------------+---------------------+------------------------------+
|  Credits meter research/deploy compute · NexusROS add-on (limited-time) · FAQ                     |
+==================================================================================================+

MK-06 · Use-cases index (the 30)

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  W H A T   W I L L   Y O U   B U I L D ?      search [__________]   filter: vertical ▾            |
+--------------------------------------------------------------------------------------------------+
|  [SaaS onboarding] [Vertical CRM] [Marketplace] [Compliance copilot] [Healthcare booking]         |
|  [Legal automation] [Fintech PFM] [Creator tool] [E-commerce] [EdTech] [Real estate] [ATS]        |
|  [Field service] [Logistics] [Hospitality] [Fitness] [Nonprofit] [Insurance] [Agritech]           |
|  [Energy] [Cybersecurity] [Dev tool] [Membership] [Events] [Travel] [Manufacturing]               |
|  [Civic/gov] [Publishing CMS] [Gaming companion] [White-label AI assistant]                       |
|  each card ▸ persona · wedge · sample product · "Build this ▸"                                     |
+==================================================================================================+

MK-07 · Solutions (per persona)

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  S O L U T I O N S                                                                                 |
|  For non-technical founders   →  idea to live product with no engineers                           |
|  For technical founders       →  own the repo, we do the 80%, you refine the 20%                  |
|  For agencies / resellers     →  white-label venture factory for your clients                     |
|  For enterprise intrapreneurs →  sovereign, compliant, on your cloud                              |
|  [ pick your path ▸ ]                                                                              |
+==================================================================================================+

MK-08 · Research / whitepapers index

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  R E S E A R C H                                                                                   |
|  · Nexus Axiom architecture & methodology (this paper)                                            |
|  · Co-evolutionary grounded ideation (ELO + Red Queen)                                            |
|  · Sovereign white-label deploy (plugin independence)                                             |
|  · Design psychology & UX (research-derived)                                                      |
|  each ▸ abstract · read (link-only) · cite                                                        |
+==================================================================================================+

MK-09 · Comparison

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  T H E   H O N E S T   C O M P A R I S O N                                                         |
|  Capability          Agencies   No-code   AI app-gen   NEXUS AXIOM                                 |
|  Grounded research      ~          no          no         yes (12-source, cited)                  |
|  Sovereign deploy       ~          no          no         yes (own repo/ns/domain)                |
|  You own the code       ~          no          ~          yes (full repo)                          |
|  Re-enter / pivot       manual     ~           no         yes (versioned)                          |
|  Horizontal scale       ~          no          no         yes (HPA/KEDA)                           |
+==================================================================================================+

MK-10 · Demo (interactive)

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  S E E   I T   B U I L D                                                                           |
|  [ ▶  interactive: type an idea → watch ideate→thesis→mockup stream into the canvas ]             |
|  input: [ "a booking app for physios" ______________________ ]  [ Run ▸ ]                         |
|  → live: tournament · thesis · product mockup appear in the artifact pane                          |
+==================================================================================================+

MK-11 · Ecosystem (NexusROS GTM add-on)

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  B U I L T   I T ?   N O W   S E L L   I T .                                                       |
|  Attach NexusROS — the AI revenue OS — to take your new venture to market.                        |
|  · account research · buying-committee reads · Monte-Carlo GTM · live deal/campaign ops           |
|  [ Add NexusROS — free for 90 days ]   (limited-time launch bundle)                               |
+==================================================================================================+

MK-12 · About / company

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  A D V E R A N T   ·   N E X U S   A X I O M                                                       |
|  Mission: collapse the distance from hypothesis to hyper-scale.                                    |
|  Part of the Nexus family (NexusROS · ProseCreator · Soverant · SignalLabs). Dublin.              |
|  [ Careers ]  [ Contact ]                                                                          |
+==================================================================================================+

MK-13 · Docs hub

+==================================================================================================+
| NEXUS AXIOM   ...nav...   search docs [__________]                        [ Start Building ▸ ]   |
+==================================================================================================+
|  D O C S            sidebar: Getting started · Stages · Chat · Repo · Deploy · Re-entry · API      |
|  ------------------------------------------------------------------------------------------------ |
|  Quickstart → your first venture in 10 minutes                                                    |
|  Concepts → stages · gates · cells · sovereignty · versioning                                     |
|  Your repo → clone, PR, CI/CD, rollback                                                           |
+==================================================================================================+

MK-14 · Blog / changelog

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                   [ Start Building ▸ ]   |
+==================================================================================================+
|  C H A N G E L O G   &   N O T E S                                                                 |
|  · v0.4 — re-entry & versioned pivots                                                             |
|  · v0.3 — full-screen chat + AG-UI artifact pane                                                  |
|  · v0.2 — sovereign white-label cells                                                             |
+==================================================================================================+

MK-15 · Privacy · MK-16 · Terms

+==================================================================================================+
| NEXUS AXIOM   ...nav...                                                                           |
+==================================================================================================+
|  PRIVACY POLICY (MK-15)                      |  TERMS OF SERVICE (MK-16)                          |
|  data residency · GDPR Art.6 · your repo is   |  license · acceptable use · sovereignty of your   |
|  yours · psychometrics never outward · DPA    |  code & data · SLA · liability · governing law    |
+==================================================================================================+

B.2 Console surfaces (CN-01 … CN-37)

Global

CN-01 · Auth / login

+==========================================================+
| NEXUS AXIOM         Sign in to build                     |
|  [ Continue with Google ] [ GitHub ] [ SSO ]             |
|  or email [___________]  [ Magic link ▸ ]  · passkey ok  |
|  your ventures, your repos                               |
+==========================================================+

CN-02 · Onboarding wizard

+==================================================================+
| Welcome to Nexus Axiom                    step 1 of 3            |
| 1 About you ▸ 2 Connect forge ▸ 3 First idea                    |
| Role [ founder ▾ ]  Team [ 1 ▾ ]  Goal [ launch ▾ ]  [ Next ▸ ] |
+==================================================================+

CN-03 · Venture workspace list

+==================================================================================+
| Ventures                                  [ + New venture ]   search [________]  |
| ● Aventra       Stage 4 · Live    app.aventra.io   ci ✓   [ open ]              |
| ● Monora (PFM)  Stage 3 · Deploy  61%              ci ⣿   [ open ]              |
| ○ Draft "SAR"   Stage 1 · Ideate  tournament       —      [ open ]              |
+==================================================================================+

CN-04 · New-venture wizard

+==================================================================+
| New venture                                  step 1 of 2         |
| Idea: [ a booking app for physios ______________________ ]       |
| App type: (•)Web ( )PWA ( )iOS ( )Android ( )iOS+Android         |
| Vertical [ Healthcare ▾ ]   User [ SMB clinics ▾ ]              |
| [ Estimate cost/time ]           [ Start ideation ▸ ]           |
+==================================================================+

CN-05 · Full-screen chat + artifact pane — the primary surface, see E1. CN-06 · Artifact split-layout renderers

+==================================================================================+
| ARTIFACT renderers      [ Doc ][ Table ][ Chart ][ Diagram ][ Code ][ Map ]      |
| Doc prose · Table sortable · Chart bars/lines · Diagram ASCII/SVG ·              |
| Code syntax+copy · Map = MapLibre (real). Agent streams into active tab (AG-UI). |
+==================================================================================+

CN-07 · PCC expanded dock

+==================================================================================+
| PROGRESS COMMAND CENTER                              [ dock ▾ ] [ clear ]         |
| research-aventra ██████░ 63%  arxiv ✓ · market ⣿ · 2 queued        [ view ]      |
| deploy-monora    ██░░░░░ 22%  scaffold ✓ · provision ⣿             [ view ]      |
| every job = a UNO run, live over WebSocket                                        |
+==================================================================================+

CN-08 · Inspector + k-cards

+=====================================+
| INSPECTOR · <selection>       [ x ] |
| [ Telemetry ][ Widgets ][ Cards ]   |
| kv     Status       healthy         |
| metric Activation   41%             |
| bar    Confidence   ████████ 0.82   |
| action [ Re-run ] ⛓UNO              |
| link   → related        (miss = "—")|
+=====================================+

CN-09 · AI-provider settings (Anthropic key like Gemini)

+==================================================================================+
| Settings · AI Providers                                     [ + Add key ]        |
| Anthropic  ● connected   models: Opus 4.8 (thinking = MAX)                        |
|   use for: [x] RESEARCH  [x] IDEATION   (quality-critical)                        |
| Gemini     ● connected   use for: [x] drafting / other stages                     |
| routing: research/ideation → Anthropic-best; else → policy tier                   |
| key stored in settings · never printed / committed                               |
+==================================================================================+

CN-10 · Billing / plans

+==================================================================+
| Settings · Billing                                               |
| Plan Builder ($XX/mo)   credits 3,200 / 5,000                    |
| add-on NexusROS GTM (90-day) [ active ]                          |
| [ Upgrade ] [ Buy credits ]  invoices ▾                          |
+==================================================================+

CN-11 · Account

+==================================================================+
| Settings · Account                                               |
| name · email · org · forge id (acme) · data region (EU)          |
| [x] psychometrics stay internal  [ Export data ] [ Delete ]      |
+==================================================================+

CN-12 · Help / command palette

+==================================================+
|  ⌘K  type a command…                             |
|  > New venture     > Re-enter stage              |
|  > Open my repo    > Estimate cost               |
|  > Ask Axiom       > Deploy / rollback           |
+==================================================+

Stage 1 · Ideate

CN-13 · Idea intake chat

+==================================================================================+
| Stage 1 · Ideate — intake                             [PCC ▂ 1]                   |
| you: "a booking app for physios, SMB clinics, iOS+Android"                        |
| Axiom: expanding into 12 candidate directions… running tournament ▸ artifact      |
+==================================================================================+

CN-14 · Tournament artifact & CN-15 · Candidate inspector (k-cards) — see E2. CN-16 · Critic-swarm (Red-Queen co-evolution)

+==================================================================================+
| ARTIFACT · Red-Queen critics                              [AG-UI ● live]         |
| candidate #3 "compliance copilot"                                                 |
|  market:   crowded — differentiate on EU data residency                          |
|  feasible: auth + audit trail non-trivial; scope v1                              |
|  research: 68% pain validated [S4]   → mutation applied → ELO re-scored           |
+==================================================================================+

CN-17 · Promote-to-research gate

+==============================================+
| GATE · Promote to Research                   |
| Top-3: SMB-OS · Vertical-CRM · Compliance    |
| [ Approve top-3 ▸ ]  [ Edit set ]   ⛓UNO     |
+==============================================+

Stage 2 · Research

CN-18 · Research chat (left column of E1) & CN-19 · Thesis artifact (right of E1). CN-20 · Sources tab

+==================================================================================+
| ARTIFACT · Sources (12)               [ Thesis ][ Sources ][ Market ][ Mobile ]  |
| [S1] arXiv 2404.xxxx  onboarding UX        [V]  [ open ]                          |
| [S4] Baymard 2025     abandonment          [V]                                   |
| [S7] NN/g 2024        mobile activation     [V]   (unverifiable → [Citation ...]) |
+==================================================================================+

CN-21 · Market tab

+==================================================================================+
| ARTIFACT · Market                     [ Market ]                                 |
| TAM \$4.1B [P] · SAM \$600M · SOM \$30M   competitors: 6 mapped                     |
| wedge: EU-sovereign booking for SMB physios                                       |
+==================================================================================+

CN-22 · Mobile-app tab

+==================================================================================+
| ARTIFACT · Mobile plan                [ Mobile ]                                  |
| targets iOS + Android (React Native) · stores App Store + Play                    |
| native: push · calendar · biometric login   est. +time/cost → CN-37 / §11        |
+==================================================================================+

CN-23 · Evidence / citation inspector

+=====================================+
| INSPECTOR · Finding #1        [ x ] |
| claim  68% abandon at step 3        |
| source [S4] Baymard 2025 [V]        |
| passage "…step 3 drop-off…"         |
| confidence ████████ 0.86            |
+=====================================+

CN-24 · Thesis-approval waitpoint (decision_room)

+==================================================================+
| GATE · Approve Thesis (waitpoint)               round 2          |
| 12 sources · confidence 0.82 · TAM \$4.1B [P]                     |
| [ Approve ▸ ] [ Request changes ] [ Re-run research ]   ⛓UNO    |
+==================================================================+

Stage 3 · Deploy

CN-25 · Pipeline stepper & CN-29 · Readiness gate — see E3. CN-26 · Cell configuration (sovereign)

+==================================================================================+
| ARTIFACT · Cell configuration                                                     |
| domain app.aventra.io ✓   TLS LetsEncrypt ✓                                       |
| namespace aventra-prod · DB role least-priv ✓ · OAuth own client ✓               |
| federation edge → ╔ Adverant control plane ╗  (BLACK BOX)                         |
+==================================================================================+

CN-27 · Scaling / HPA (hpc_dashboard)

+==================================================================================+
| ARTIFACT · Scaling                                                                |
| web    min 3 max 15  cpu 70% ████░  KEDA queue ✓                                  |
| worker min 2 max 10  mem 80% ███░░   gauges: RPS · p95 · queue depth              |
+==================================================================================+

CN-28 · Skills / bindings roster

+==================================================================================+
| ARTIFACT · Skills & bindings                                                      |
| [ auth ] [ payments ] [ notifications ] [ calendar ] [ search ]  [ + bind ]       |
| each ⛓ bound via UNO 5-gate broker                                                |
+==================================================================================+

Stage 4 · Live

CN-30 · Product drilldown — see E4. CN-31 · Monitoring (nexus-alive)

+==================================================================================+
| ARTIFACT · Live monitoring (nexus-alive)                                          |
| uptime 99.98% · errors 0.2% · p95 240ms · self-heal 1 (auto)                     |
| alerts: [ok] scale-up 3→5 · [ok] cert renew                                       |
+==================================================================================+

CN-32 · PID library + deliverables catalog

+==================================================================================+
| ARTIFACT · PID library & deliverables catalog                                     |
| PID (PRINCE2): business case · project plan · risk register · quality plan        |
| deliverables: paper · GTM · patents · mockups · docs · deployed app               |
| all committed to your repo · [ open repo ] [ export ]                            |
+==================================================================================+

Version control & re-entry

CN-33 · Source-repo browser & CN-34 · Version history / diff / rollback — see E12. CN-35 · Re-enter / pivot panel

+==================================================================+
| RE-ENTER / PIVOT                     current: Stage 4 · Live     |
| jump to:  ( ) Ideate  ( ) Research  ( ) Deploy                   |
| change: [ pivot SMB → mid-market ______________ ]              |
| creates a branch → gated re-run → versioned re-deploy (revert)   |
| [ Start pivot ▸ ]                                               |
+==================================================================+

CN-36 · CI/CD run board (Forgejo Actions)

+==================================================================================+
| CI/CD · Forgejo Actions                                                           |
| #a1c  build ✓  trivy ✓  cosign ✓  rollout ✓   tag v0.4.1                         |
| #9f2  build ✓  trivy ✓  cosign ✓  rollout ✓   tag v0.4.0                         |
| [ re-run ]   [ rollback to v0.4.0 ]                                              |
+==================================================================================+

CN-37 · Cost / complexity quote estimator

+==================================================================================+
| COST / TIME ESTIMATOR                                                              |
| app type (•) iOS+Android   complexity [ medium ▾ ]   surfaces 14                  |
| -------------------------------------------------------------------------------- |
| est. build   ~T hrs wall + gates     research tokens (Opus max) ~N               |
| est. credits ~C                        est. price $P   (margin band M)            |
| driver: frontier Anthropic tokens dominate COGS  → see §11                        |
+==================================================================================+

CN-38 · The Refine Loop (propose → refine → approve) — the flagship surface at every stage

+==================================================================================================+
| NEXUS AXIOM  Aventra ▸ Review & Refine            (the most important step — appears every stage) |
+---------------------------+----------------------------------------------------------------------+
| UNIFIED CHAT        [ ⤢ ] | ARTIFACT · Proposed plan  (v3)                    [ refine · approve ] |
|                           | -------------------------------------------------------------------- |
| you: make it mid-market,  |  Plan · Stage 3 · Deploy                                              |
|      drop the free tier   |   1. Provision sovereign cell (EU)              (unchanged)           |
| Axiom: updated — changes  |   2. ~~Free tier~~ → paid-only onboarding      (changed ◂ you)       |
|   highlighted below       |   3. Target ~~SMB~~ → mid-market clinics       (changed ◂ you)       |
| you: good, ship it        |   4. iOS + Android, biometric login            (unchanged)           |
|                           | -------------------------------------------------------------------- |
| [ Refine further... ] (>) |  diff vs v2 · plan is versioned      [ Approve & run ▸ ]  [ Undo ]   |
+---------------------------+----------------------------------------------------------------------+
| engine invisible — no toolchain shown; branded "Axiom"        PCC ▸ idle until you approve         |
+==================================================================================================+

The Refine Loop wraps every gate (CN-17, CN-24, CN-29, live edits, and re-entry CN-35): each stage first shows a proposed plan the user iteratively refines and approves before anything runs. The mechanism (agentic planning) is never surfaced.

CN-38 variants · the Refine Loop at every stage (one loop; stage-specific proposed plan)

 @ IDEATE — Proposed direction (v2)          @ RESEARCH — Proposed thesis scope (v2)
   1 Wedge: SMB onboarding OS      (=)          - add mobile-activation evidence   (◂ you)
   2 ~~broad SMB~~ → physio clinics (◂ you)     - drop payments deep-dive          (◂ you)
   [ Approve & research ▸ ] [ Refine ]          [ Approve thesis ▸ ] [ Refine ]

 @ DEPLOY — see CN-38 (Proposed plan v3)      @ LIVE — Proposed change to app.aventra.io (v5)
                                                 - add pricing page + annual toggle (◂ you)
                                                 [ Approve & re-deploy ▸ ] [ Refine ]  (revertible)

Same branded "Review & Refine" surface each time — proposed plan, your edits diffed, versioned, approve-to-run. No "Claude Code", no plan-mode, no tool names anywhere.

B.3 Archetype gallery (AR-01 … AR-15)

Structural skeletons from archetypes.py (generated with _ck alignment at execution); each notes its Nexus Axiom use.

AR-01 · graph_explorer — canvas + right inspector. Use: relationship/ontology views.

+ graph_explorer -------------------------+ inspector -+
| query [________]                        | selected   |
|   (o)──(o)     canvas: nodes + edges    | kv / action|
|    │    │                               |            |
|   (o)──(o)──(o)                         |            |
+ footer: legend --------------------------+-----------+

AR-02 · wizard — left step rail + fields + result. Use: new-venture wizard, onboarding.

+ wizard --------------------------------------------+
| banner                                             |
| 1●─2○─3○ | field [____]  field [____]              |
|   rail   | field [____]                            |
|          | result preview                          |
+ [ Back ] [ Next ▸ ] --------------------------------+

AR-03 · ledger — filter + table + row drawer. Use: version history, CI runs, sources.

+ ledger ---------------------------------------------+
| filter [__]  col1     col2      col3     ▾          |
| ------------------------------------------          |
| row  a1c      build    ✓        2m       [ open ]   |
| row  9f2      pivot     ✓        1d     ┌ drawer ┐  |
+ footer -------------------------------- └────────┘--+

AR-04 · ring_analyzer — cycle diagram + legs. Use: dependency/loop analysis (rare).

+ ring_analyzer -------------------------------------+
|      (A)──►(B)                                      |
|       ▲      │      legs:  A→B  qty  x              |
|      (D)◄──(C)             C→D  qty  y              |
+----------------------------------------------------+

AR-05 · card_grid_modal — card grid + bind dialog. Use: skills/bindings, marketplace, use-case index.

+ card_grid_modal -----------------------------------+
| [ card ] [ card ] [ card ]        ┌ modal ───────┐ |
| [ card ] [ card ] [ card ]        │ bind skill   │ |
|                                   │ [ confirm ]  │ |
+-----------------------------------└──────────────┘-+

AR-06 · map_ops — layers + 2D map + ticker. Use: geo product surfaces (UC field-service/logistics).

+ map_ops -------------------------------------------+
| layers  | [ 2D map canvas · MapLibre (real) ]      |
| [x] A   |                                           |
| [ ] B   |                                           |
+ ticker: events ------------------------------------+

AR-07 · globe_rmp — globe + tracks + status. Use: global fleet/logistics (UC-14).

+ globe_rmp -----------------------------------------+
|      .-""-.        tracks:  T1 ···                  |
|     ( globe )               T2 ···                  |
|      '-..-'        status:  ● ● ●                   |
+----------------------------------------------------+

AR-08 · stix_board — 3-column kanban. Use: pipeline/kanban product surfaces (ATS, CRM).

+ stix_board ----------------------------------------+
| New        | In progress   | Done                  |
| [item]     | [item]        | [item]                |
| [item]     |               | [item]                |
+ footer --------------------------------------------+

AR-09 · ownership_tree — hierarchy. Use: org/entity trees (UC compliance, gov).

+ ownership_tree ------------------------------------+
| Root                                               |
|  ├─ Node A                                         |
|  │   └─ Leaf                                        |
|  └─ Node B                                          |
+----------------------------------------------------+

AR-10 · video_studio — tabs + frame + timeline. Use: media/CMS product (UC-28).

+ video_studio --------------------------------------+
| [ tabs ]     [ frame / preview ]                   |
|              [ ................ ]                   |
| timeline |=====●------------------|                |
+ footer --------------------------------------------+

AR-11 · cap_composer — form + matrix + targets. Use: broadcast/notify composers (alerts).

+ cap_composer --------------------------------------+
| compose form   | severity matrix | targets         |
| [__________]   |  ▢ ▢ ▢          | [x] A [ ] B     |
+----------------------------------------------------+

AR-12 · command_dashboard — KPI tiles + feed. Use: Live scorecard, monitoring, admin dashboards.

+ command_dashboard ---------------------------------+
| [ KPI ] [ KPI ] [ KPI ] [ KPI ]                    |
| ---------------------------------                  |
| feed: alert · alert · alert                        |
+----------------------------------------------------+

AR-13 · hpc_dashboard — jobs + gauges. Use: scaling/HPA view (CN-27), build jobs.

+ hpc_dashboard -------------------------------------+
| jobs                         | gauges              |
| #1 build   running  ⣿        | cpu ████░           |
| #2 rollout queued            | mem ███░░           |
+----------------------------------------------------+

AR-14 · settings_form — sectioned config. Use: AI-provider settings (CN-09), account, cell config.

+ settings_form -------------------------------------+
| Section A                                          |
|   label [____]   toggle [x]                        |
| Section B                                          |
|   label [____]                    [ Save ]         |
+----------------------------------------------------+

AR-15 · decision_room — transcript + gate. Use: every Refine-Loop gate (CN-24/17/29/38).

+ decision_room -------------------------------------+
| transcript                                         |
|  you:  change X                                    |
|  axiom: updated → diff                             |
| -------------------------------------------------- |
| GATE:  [ Approve ▸ ]   [ Send back ]               |
+----------------------------------------------------+

B.4 User-flow diagrams (UF-01 … UF-15)

UF-01 · End-to-end lifecycle — see E6. UF-10 · Model routing — see E7. UF-13 · Re-entry/pivot — see E11. UF-14 · Version control + CI/CD — see E13.

UF-02 · Ideate (ELO + Red Queen)

  idea ─► generate N candidates ─► pairwise LLM-judge duels (Claude Opus) ─► ELO update
            ▲                                                                     │
            │                     Red Queen: critics co-evolve ◄──────────────────┤
            └── mutate top-k (OptimizerService) ◄── keep if fitness ≥ 60 ◄─────────┘
                       │
                       ▼ converged → top-3 ─► [Refine Loop gate] ─► Research

UF-03 · Research (STORM / arXiv)

  question ─► Planner ─► Retriever [arXiv/GraphRAG/web] ─► Analysis ─► Evaluator (≥60)
                                                                          │
                   waitpoint ◄── Aggregator ◄── Optimizer ◄──────────────┘
                       │
                       ▼ [Refine Loop: approve thesis] ─► Deploy

UF-04 · Deploy (sovereign cell)

  approved thesis ─► scaffold repo (forge) ─► provision cell (ns/db/oauth/tls) ─► wire skills
                                                                                     │
     go-live ◄── readiness gate 7/7 ◄── scale (HPA/KEDA) ◄── CI build/scan/sign ◄────┘

UF-05 · Live / gating

  live ─► monitor (nexus-alive) ─► issue?
                                     │ yes
                    [Refine Loop] ◄──┘ ─► propose fix ─► approve ─► re-deploy (versioned)

UF-06 · Auth / onboarding

  visitor ─► sign in (OAuth/passkey/magic) ─► onboarding wizard ─► connect forge identity ─► first venture

UF-07 · UNO dispatch → 5-gate broker → workflows

  UI action ─► POST /api/v1/dispatch ─► UNO resolve skill ─► 5-gate broker
     (classification·residency·export·spend·safety) ─► BullMQ ─► nexus-workflows (executor)
                                          ◄── run row + PCC (WS) ──┘

UF-08 · Chat streaming (WS → SSE fallback)

  send ─► Socket.IO ─► tokens ─► render
            │ 3+ failures
            ▼ NexusSSEClient POST /api/nexus ─► ReadableStream ─► render

UF-09 · AG-UI / MCP artifact generation

  agent turn ─► MCP tool call ─► result ─► AG-UI event (component spec) ─► artifact pane renders live

UF-11 · Human-gate / approval (the Refine Loop)

  proposed plan (vN) ─► user refines ─► live-refactor → diff (vN+1) ─► approve?
         ▲                                                               │ no → loop
         └───────────────────────────────────────────────────────────────┘
                                      │ yes
                                      ▼ execute (dispatch → UNO)

UF-12 · Error & recovery

  step fails ─► UNO step-failed ─► PCC error (what/why/fix)
                                      │
                  [ Retry ]   [ Rollback = git revert ]   [ Refine plan ]

UF-15 · Deployed-site edit → gated re-deploy

  edit (chat) ─► [Refine Loop: propose change] ─► approve ─► branch/commit (forge)
                                                                 │
     live (new tag) ◄── rollout ◄── CI build/scan/sign ◄────────┘   (revertible)

B.5 Customer-journey maps (CJ-01 … CJ-05) — before→after per stage

CJ-01 · Non-technical solo founder ("Maya") — see E8.

CJ-02 · Technical founder

  ┌ Ideate ─────┐  ┌ Research ───┐  ┌ Deploy ─────┐  ┌ Live ───────┐  ┌ Re-enter ───┐
  │ builds MVP  │  │ skips lit   │  │ writes      │  │ maintains   │  │ rewrites    │
  │  ───────►   │  │  ───────►   │  │ boilerplate │  │ infra alone │  │ from scratch│
  │ ranks ideas │  │ 12-source   │  │  ───────►   │  │  ───────►   │  │  ───────►   │
  │ (ELO)       │  │ thesis free │  │ owns repo,  │  │ self-heal + │  │ pivot = a   │
  │             │  │             │  │ 80% done    │  │ HPA free    │  │ branch      │
  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘
   keeps full control of the code · refines the 20% that matters

CJ-03 · Agency / white-label reseller

  ┌ Pitch ──────┐  ┌ Build ──────┐  ┌ White-label ┐  ┌ Handover ───┐  ┌ Scale ──────┐
  │ scope docs  │  │ 3-mo cycle  │  │ brand leaks │  │ manual      │  │ 1 client at │
  │  ───────►   │  │  ───────►   │  │  ───────►   │  │ deploy      │  │ a time      │
  │ live demo   │  │ days/client │  │ zero reveal │  │  ───────►   │  │  ───────►   │
  │             │  │             │  │ sovereign   │  │ client owns │  │ venture     │
  │             │  │             │  │             │  │ their repo  │  │ factory     │
  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘

CJ-04 · Enterprise intrapreneur

  ┌ Approval ───┐  ┌ Research ───┐  ┌ Compliance ─┐  ┌ Deploy ─────┐  ┌ Govern ─────┐
  │ 6-mo budget │  │ analyst wks │  │ months of   │  │ central IT  │  │ shadow-IT   │
  │  ───────►   │  │  ───────►   │  │ review      │  │ queue       │  │ risk        │
  │ pilot in wk │  │ cited thesis│  │  ───────►   │  │  ───────►   │  │  ───────►   │
  │             │  │             │  │ sovereign,  │  │ own cell +  │  │ audit trail │
  │             │  │             │  │ EU data     │  │ own repo    │  │ + gates     │
  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘

CJ-05 · SMB operator

  ┌ Problem ────┐  ┌ Describe ───┐  ┌ Review ─────┐  ┌ Live ───────┐  ┌ Iterate ────┐
  │ off-shelf   │  │ can't brief │  │ can't read  │  │ pays SaaS   │  │ stuck w/    │
  │ misfit      │  │ a developer │  │ specs       │  │ that misfits│  │ vendor      │
  │  ───────►   │  │  ───────►   │  │  ───────►   │  │  ───────►   │  │  ───────►   │
  │ own tool    │  │ chats idea  │  │ Refine Loop │  │ own tool,   │  │ pivots by   │
  │             │  │ plainly     │  │ in words    │  │ own data    │  │ chatting    │
  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘

B.6 App-only architecture atlas (AT-01 … AT-15) — backend always a sealed black box

AT-02 · Tenant-cell topology — see E9.

AT-01 · App context

  [ founder ] ─► ( Nexus Axiom app ) ─► generates ─► [ deployed venture product ]
                        │
                        └─► federation edge ─► ╔ Adverant backend (BLACK BOX) ╗

AT-03 · Chat + artifact component graph

  UnifiedChatPanel ─┬─ ChatSurfaceShell ─ CmaSidebarOverlay (memory)
                    ├─ ChatPane / bubbles / input
                    └─ ArtifactPanel ─ 25 renderers ─ ArtifactSplitLayout (AG-UI)
   PluginContextBridge feeds host context · dock: right|bottom|float|popout

AT-04 · UNO dispatch spine

  every action ─► lib/dispatch ─► POST /api/v1/dispatch ─► UNO ─► 5-gate broker ─► BullMQ ─► workflows
                              (one governed spine — no forks)

AT-05 · PCC / WebSocket data flow

  workflows ─► run events ─► UnifiedWSProvider (Socket.IO) ─► PCC store (zustand+persist)
       server DB (truth) ◄── hydrate/correct ──┘ ─► ProgressCommandCenter dock

AT-06 · Inspector / k-card data flow

  selection-context ─► InspectorProfile.tabs ─► renderKbCard(KbCardDef, subject) ─► ros atoms
       action k-card ─► runAction ─► UNO ;   missing value ─► "—" (no fabrication)

AT-07 · Federation edge (backend sealed)

  cell ─► mTLS federation edge (versioned, authed) ─► ╔ control plane (BLACK BOX) ╗
       secrets never cross to client · brand resolved at edge SSR

AT-08 · Deploy / scale topology

  ingress (nginx/istio + cert-manager) ─► web (HPA 3→15) ─► worker (HPA 2→10, KEDA)
       StatefulSet: own DB per cell   ·   namespace = venture cell

AT-09 · AI-provider routing

  job ─► classify stage ─► [ ideate/research → Anthropic Opus max-think ] | [ other → policy tier ]
       keys from AI-provider settings (never client-exposed)

AT-10 · App data model (own DB schema)

  venture · plan_version · artifact · deployment · repo_ref · credit_ledger · gate_event
       least-priv DB role per cell · own schema (sovereignty)

AT-11 · AG-UI / MCP generative-UI pipeline

  agent ─► MCP tool ─► result ─► AG-UI event ─► component spec ─► renderer ─► artifact pane

AT-12 · Sequence — one gated action

  user click ─► dispatch ─► UNO gates ─► workflow step ─► result ─► artifact update ─► PCC done

AT-13 · VCS / repo topology

  per-venture repo  forge.adverant.ai/<org>/<venture>   main ⇄ develop (GitFlow, PR-gated)
       docs/mockups · src · k8s · .forgejo   ·   customer has full clone/PR access

AT-14 · CI/CD pipeline

  commit ─► Forgejo Actions: build ─► trivy ─► cosign ─► OCI registry ─► k3s rollout ─► cell
       deploy tied to tag · rollback = git revert

AT-15 · Pattern Learning Substrate (internal-only; generalized concepts out)

  [ NexusROS · Soverant · SignalLabs · ProseCreator · NexusQA · dashboard · new ventures ]
        │  nexus-reposwarm indexes architecture / code-patterns / approaches
        ▼
  ╔══════════════ GraphRAG Pattern Library (INTERNAL — never exposed) ══════════════╗
  ║  generalized patterns · approaches · abstractions   (no verbatim proprietary code) ║
  ╚═══════════════════════════════════╤════════════════════════════════════════════════╝
                                      │  generalized concepts only  ── IP firewall + anti-reproduction ──►
                                      ▼
              Ideate (§2)  +  Code-gen (§4)  ─►  ORIGINAL new app  (customer's own repo)
   cross-customer isolation absolute · consent-gated flywheel · user sees concepts, never internals

B.7 Use cases (UC-01 … UC-30) — full surface set each

Per use case: (M) marketing landing · (H) product hero · (S) key sub-screen · (F) core flow. All generated into the customer's own forge repo, re-enterable and versioned; each product is white-labelled (its own brand, not "Nexus Axiom").

UC-01 · SMB onboarding SaaS — "OnBoardly" · SaaS founder · cut activation drop-off · web+PWA

(M) +------------------------------------------+   (H) +------------------------------------------+
    | OnBoardly   Features Pricing [Start free]|       | OnBoardly  Flows Users Analytics   ⚙     |
    | "Turn signups into activated users."     |       | Activation 41% ▲   step-3 drop ⚠         |
    | [ hero visual ]   [ Get started ]        |       | [ flow: welcome → connect → aha ]        |
    | steps · proof · pricing · CTA            |       | segment: trial | paid                    |
    +------------------------------------------+       +------------------------------------------+
(S) +------------------------------------------+   (F) signup ─► guided steps ─► aha ─► activated ─► paid
    | Flow "New user"              [ Publish ] |            (auto-nudge on drop-off)
    | 1 welcome  2 connect  3 aha ← 68% [fix]  |
    +------------------------------------------+

UC-02 · Vertical CRM — "CliniCRM" · clinic owner · industry-fit pipeline · web

(M) "The CRM built for clinics."  [Book demo]      (H) CliniCRM  Pipeline Patients Tasks  ⚙
(S) Patient record: history · consent · next appt   (F) lead ─► consult ─► treatment plan ─► follow-up

UC-03 · Two-sided marketplace — "TradePair" · marketplace founder · liquidity · web+PWA (hero: E14)

(M) "Find a vetted pro in minutes."  [List / Hire]  (H) see E14 (search · cards · filters · cart)
(S) Provider profile: reviews · rates · [ Book ]    (F) search ─► compare ─► book ─► pay ─► review

UC-04 · Compliance / reg copilot — "ReguMate" · compliance lead · faster attestations · web

(M) "Prove compliance, continuously."  [Get audit] (H) ReguMate  Controls Evidence Audits  ⚙
(S) Control detail: requirement · evidence · owner  (F) map controls ─► collect evidence ─► attest ─► audit

UC-05 · Healthcare booking — "CareBook" · clinic/patient · easy booking · iOS+Android (hero: E14)

(M) "Care, booked in seconds."  [Get the app]      (H) see E14 (symptom → specialty → slots → Book)
(S) Visit detail: provider · time · telehealth ✓    (F) symptom ─► match ─► book ─► reminder ─► visit

UC-06 · Legal doc automation — "Clausely" · small-firm lawyer · draft faster · web

(M) "Contracts in minutes, not hours."  [Try free] (H) Clausely  Templates Drafts Clauses  ⚙
(S) Draft view: clause library · risk flags · track (F) pick template ─► fill ─► review flags ─► export

UC-07 · Fintech PFM — "Monora" · consumer · clarity on money · iOS+Android (hero: E14)

(M) "Your money, finally clear."  [Get the app]     (H) see E14 (net worth · budgets · insights)
(S) Budget detail: category caps · alerts · trend   (F) link accounts ─► categorize ─► budget ─► save

UC-08 · Creator monetization — "Patronize" · creator · recurring income · web+PWA

(M) "Get paid for your work."  [Start earning]      (H) Patronize  Posts Members Payouts  ⚙
(S) Tiers: perks · price · member count             (F) publish ─► subscribe ─► deliver perks ─► payout

UC-09 · E-commerce storefront+ops — "Shoply" · seller · sell in a day · web

(M) "Sell anywhere in a day."  [Open store]         (H) Shoply  Products Orders Ops  ⚙
(S) Order: items · fulfilment · refund              (F) list ─► order ─► fulfil ─► ship ─► review

UC-10 · EdTech course platform — "Learnly" · educator · monetize expertise · web+PWA

(M) "Teach what you know."  [Create a course]       (H) Learnly  Courses Students Revenue  ⚙
(S) Lesson editor: video · quiz · progress          (F) build ─► enroll ─► learn ─► certify

UC-11 · Real-estate listings/analytics — "Estately" · agent · faster closes · web

(M) "Listings that sell themselves."  [List]        (H) Estately  Listings Leads Analytics  ⚙  (map)
(S) Listing: photos · price history · map           (F) list ─► inquiry ─► viewing ─► offer ─► close

UC-12 · Recruiting ATS — "HireLoop" · recruiter · organized hiring · web

(M) "Hire without the chaos."  [Post a job]         (H) HireLoop  Jobs Candidates Pipeline  ⚙ (kanban)
(S) Candidate: resume · scorecard · stage           (F) post ─► apply ─► screen ─► interview ─► offer

UC-13 · Field-service dispatch — "DispatchIQ" · ops manager · route techs · web+Android

(M) "Right tech, right job, on time."  [Book demo]  (H) DispatchIQ  Jobs Techs Map  ⚙  (map_ops)
(S) Job: location · assigned tech · status          (F) request ─► assign ─► route ─► complete ─► invoice

UC-14 · Logistics / fleet — "FleetTrace" · fleet owner · visibility · web

(M) "Every vehicle, one screen."  [Track fleet]     (H) FleetTrace  Fleet Routes Alerts  ⚙  (globe_rmp)
(S) Vehicle: location · fuel · ETA                  (F) plan ─► dispatch ─► track ─► deliver ─► report

UC-15 · Hospitality ordering — "TableTurn" · restaurateur · faster turns · iOS+Android

(M) "Order at the table, instantly."  [Get it]      (H) TableTurn  Menu Orders Tables  ⚙
(S) Order: items · course timing · pay              (F) scan ─► order ─► kitchen ─► serve ─► pay

UC-16 · Fitness / wellness coaching — "FitPath" · coach · retain clients · iOS+Android

(M) "Coaching that sticks."  [Start free]           (H) FitPath  Clients Plans Progress  ⚙
(S) Client: plan · adherence · check-in             (F) assess ─► plan ─► track ─► adjust ─► retain

UC-17 · Nonprofit donor CRM — "GiveGrid" · nonprofit lead · grow giving · web

(M) "Turn supporters into sustainers."  [Demo]      (H) GiveGrid  Donors Campaigns Reports  ⚙
(S) Donor: history · segments · asks               (F) acquire ─► cultivate ─► ask ─► steward ─► renew

UC-18 · Insurance quote/claims — "ClaimEase" · broker · faster claims · web

(M) "Quote and claim, without the wait."  [Start]   (H) ClaimEase  Quotes Policies Claims  ⚙
(S) Claim: docs · status · payout                  (F) quote ─► bind ─► claim ─► review ─► pay

UC-19 · Agritech farm management — "AgriGrid" · grower · yield + inputs · web+Android

(M) "Grow more, waste less."  [Start]               (H) AgriGrid  Fields Crops Weather  ⚙  (map_ops)
(S) Field: soil · irrigation · yield est.           (F) map fields ─► plan ─► monitor ─► harvest ─► report

UC-20 · Energy / utility monitoring — "GridWatch" · facility mgr · cut usage · web

(M) "See every watt."  [Book demo]                  (H) GridWatch  Sites Usage Alerts  ⚙ (command_dashboard)
(S) Site: load curve · anomalies · cost             (F) connect meters ─► monitor ─► alert ─► optimize

UC-21 · Cybersecurity posture — "PostureIQ" · security lead · prove posture · web

(M) "Know your risk. Prove it."  [Scan]             (H) PostureIQ  Assets Findings Score  ⚙ (stix_board)
(S) Finding: severity · asset · remediation         (F) discover ─► assess ─► prioritize ─► remediate ─► report

UC-22 · Developer tool / API product — "APIForge" · dev-tools founder · ship API · web

(M) "Your API, production-ready."  [Get keys]       (H) APIForge  Endpoints Keys Usage Docs  ⚙
(S) Endpoint: schema · playground · logs            (F) define ─► test ─► publish ─► meter ─► bill

UC-23 · Membership / community — "Circlely" · community lead · engagement · web+PWA

(M) "Where your people gather."  [Start free]       (H) Circlely  Feed Spaces Events Members  ⚙
(S) Space: threads · roles · rules                  (F) join ─► post ─► engage ─► upgrade ─► retain

UC-24 · Events / ticketing — "Gatherly" · organizer · sell tickets · web+PWA

(M) "Sell out your next event."  [Create event]     (H) Gatherly  Events Tickets Attendees  ⚙
(S) Event: tiers · sales · check-in                 (F) create ─► promote ─► sell ─► check-in ─► follow-up

UC-25 · Travel itinerary planner — "Roamly" · traveler · effortless trips · iOS+Android

(M) "Plan the whole trip in minutes."  [Get app]    (H) Roamly  Trips Map Bookings  ⚙  (map)
(S) Day plan: stops · times · map route             (F) describe ─► plan ─► book ─► navigate ─► remember

UC-26 · Manufacturing / inventory — "MakerFlow" · plant mgr · track stock/WIP · web

(M) "Inventory and WIP, in real time."  [Demo]      (H) MakerFlow  Inventory Orders WIP  ⚙
(S) Item: stock · reorder point · location          (F) receive ─► produce ─► track WIP ─► ship ─► reorder

UC-27 · Civic / gov services portal — "CivicOne" · agency · citizen services · web

(M) "Government services, made simple."  [Explore]  (H) CivicOne  Services Requests Status  ⚙
(S) Request: form · documents · status              (F) find service ─► apply ─► verify ─► track ─► resolve

UC-28 · Media / publishing CMS — "Presswave" · publisher · publish faster · web

(M) "Publish anywhere, beautifully."  [Start]       (H) Presswave  Stories Media Schedule  ⚙ (video_studio)
(S) Story: editor · media · SEO · schedule          (F) draft ─► edit ─► review ─► publish ─► distribute

UC-29 · Gaming community companion — "GuildHub" · community founder · retention · web+iOS+Android

(M) "Your guild's home base."  [Create guild]       (H) GuildHub  Guilds Events Stats  ⚙
(S) Member: roles · stats · achievements            (F) join ─► play ─► track stats ─► organize ─► retain

UC-30 · White-label vertical AI assistant — "AssistIQ" · SMB/agency · branded AI helper · web+PWA

(M) "Your own AI assistant, your brand."  [Build]   (H) AssistIQ  Chat Knowledge Skills  ⚙ (full-screen chat)
(S) Skill/knowledge: sources · tools · guardrails   (F) ingest ─► configure ─► chat ─► act ─► improve

---

Appendix B is complete — every catalog artifact is drawn: 16 marketing + 38 console (incl. the Refine Loop) + 15 archetypes + 15 user-flows + 5 customer-journeys + 14 architecture + 30 use cases × full surface set. At execution these regenerate via archetypes.py (alignment-guaranteed) and are committed to the paper's figures and each venture's repo. Color/type come from the research-derived design system (§6); the backend is always a sealed black box.

---

Appendix A. Implementation Guide (Build-Ready)

This appendix consolidates the paper into a single "build it from here" reference. It assumes the methodology volumes as prior reading: it does not re-derive the ideation tournament (see §2, Ideation), the deploy and interaction spine (see §4, Deploy), the Refine Loop and its convergence model (see §7, the Refine Loop), or the Pattern Learning Substrate and IP firewall (see §8, the Pattern Substrate). It restates only what an engineering team must assemble: the module map, the per-cell data schema, the end-to-end path of one gated action, the AI-provider routing contract, and a phase order in which to build. Every code fragment is interface-level and illustrative; the Adverant backend remains a sealed boundary, addressed only through contracts.

A.1 Module Map

A venture runs as a sovereign cell — its own namespace, database, identity realm, domain, repository, and CI lineage (see §4, Deploy). Within a cell, seven modules divide the work. The load-bearing invariant across all of them: no module produces a side effect on its own authority. Everything consequential funnels through the Unified Nexus Orchestrator (UNO) dispatch client into the five-gate broker.

The shared brain — CMA's 13 patterns on nexus-graphrag, the generalized-pattern index (see §8, the Pattern Substrate) — is pooled and sits behind the federation edge; everything a customer or auditor can observe is siloed per cell [Chong 2006; Kumar 2026].

A.2 App Data Schema (own DB per cell)

Each cell owns an isolated database with private credentials (see §4.1). The application schema is small and blackboard-shaped: the Refine Loop writes plan_version and gate_event, the executor writes artifact and deployment, and the broker writes credit_ledger. We give the row types as TypeScript with the SQL intent inlined; identifiers are cell-local, and no row carries a pointer to any sibling tenant.

TypeScript
78 lines
Copy
// Per-cell application schema (illustrative; interface-level).
// All ids are UUID PKs; all *_at are timestamptz; tenant scope = the cell itself.

interface Venture {                         // table: venture
  id: string;                               // PK
  slug: string;                             // unique within cell
  stage: 'catalyst' | 'thesis' | 'crucible' | 'apex';  // human-gated stage (§2–§5)
  brandDomain: string;                      // resolved at edge (§4.1)
  status: 'active' | 'archived';
  createdAt: string;
}

interface PlanRevision {                     // table: plan_version  (Refine Loop ledger, §7; distinct from the §5 version-graph PlanVersion)
  id: string;                               // PK
  ventureId: string;                        // FK -> venture.id
  parentId: string | null;                  // prior revision; null = initial Propose
  stage: Venture['stage'];
  intentDigest: string;                     // system paraphrase of what it heard
  steps: PlannedStep[];                     // each step is a would-be DispatchRequest
  status: 'proposed' | 'refining' | 'approved' | 'superseded';
  gapEstimate: number | null;               // g(p,u*) proxy; monotone-decreasing (§7)
  approvedBy: string | null;                // userId; only set on 'approved'
  createdAt: string;
}

interface PlannedStep {                     // embedded in plan_version.steps (jsonb)
  ordinal: number;
  dispatch: Partial<DispatchRequest>;       // drawn, not fired, until approve (§7.1)
  rationale: string;
}

interface Artifact {                        // table: artifact  (AG-UI pane state, §4.4)
  id: string;                               // PK
  ventureId: string;                        // FK
  correlationId: string;                    // ties to the dispatch that produced it
  kind: string;                             // renderer key (e.g. 'blueprint','deploy-diff')
  revision: number;                         // bumped on each AG-UI patch
  payload: unknown;                         // typed per renderer; jsonb
  updatedAt: string;
}

interface Deployment {                      // table: deployment  (Crucible output, §4)
  id: string;                               // PK
  ventureId: string;                        // FK
  repoRefId: string;                        // FK -> repo_ref.id
  commitSha: string;                        // exact tree rolled out
  imageDigest: string;                      // cosign-signed OCI digest
  phase: 'building' | 'scanning' | 'signing' | 'rolling' | 'live' | 'failed';
  rollbackOf: string | null;               // git-revert lineage; recovery = forward path
  createdAt: string;
}

interface RepoRef {                         // table: repo_ref  (per-venture forge repo, §4)
  id: string;                               // PK
  ventureId: string;                        // FK
  forgeUrl: string;                         // Forgejo repo (venture-owned)
  defaultBranch: string;
  ciPipeline: 'forgejo-actions';            // build->trivy->cosign->OCI->k3s
}

interface CreditLedger {                    // table: credit_ledger  (spend gate substrate)
  id: string;                               // PK
  ventureId: string;                        // FK
  correlationId: string | null;            // debit tied to a dispatch; null = top-up
  delta: number;                            // + credit grant, - metered usage
  balanceAfter: number;                     // running balance, enforced by spend gate
  reason: string;
  createdAt: string;
}

interface GateEvent {                       // table: gate_event  (broker audit trail, §4.4)
  id: string;                               // PK
  correlationId: string;                    // the dispatch under evaluation
  gate: 'classification' | 'data-residency' | 'export-class' | 'spend' | 'safety';
  verdict: 'allow' | 'deny';
  reason: string | null;                    // human-legible on deny
  createdAt: string;
}

Two schema-level guarantees follow the paper's guardrails. gate_event is append-only and indexed by correlationId, so every allow/deny is reconstructible; and plan_version retains the full parentId chain, so a Refine Loop dialogue — and any re-entry or versioned pivot (see §5, Live) — is fully auditable after the fact.

A.3 End-to-End Sequence of One Gated Action

A single user intent — "approve the deploy plan," "rename the marketplace," a button in a k-card — travels one path. Algorithm A.1 is that path stitched together; it calls GatedDispatch (Algorithm 4.2 in §4) as its broker subroutine and shows where each table in §A.2 is written.

Plain Text
32 lines
Copy
Algorithm A.1  GatedAction  (one user intent, end-to-end)
Input:  user intent i on venture v; sessionId sid; selection ctx (optional)
Output: live artifact + PCC narration, or a legible denial

 1  // --- UI: browser, no side effects yet ---
 2  cid   <- newCorrelationId()
 3  d     <- buildDispatchRequest(i, v, sid, cid)   // jobType resolves to a skill
 4  openStreams(cid)                                // subscribe AG-UI + PCC to cid
 5
 6  // --- Dispatch client -> cell API ---
 7  res   <- POST /api/v1/dispatch (d)              // UNO single entrypoint
 8
 9  // --- Five-gate broker (Algorithm 4.2, §4) ---
10  for gate in [classification, dataResidency, exportClass, spend, safety]:
11      verdict <- gate.evaluate(d, skill)
12      writeRow(gate_event, {cid, gate, verdict})  // append-only audit
13      if verdict = DENY:
14          if gate = spend: /* no debit written */
15          emitPCC(cid, "dispatch.denied", gate.name)
16          return renderDenial(gate.name, verdict.why)   // surface shows reason
17  debit(credit_ledger, v, cid, cost(skill))       // spend gate passed -> meter
18
19  // --- Executor: nexus-workflows (sole executor) ---
20  job   <- bullmq.enqueue(d.jobType, d, key = cid)
21  emitPCC(cid, "dispatch.accepted", job.id)
22  workflows.execute(job):                          // dequeues; black box internally
23      stream AG-UI events -> upsert(artifact, {cid, revision++})  // pane live-updates
24      stream progress     -> emitPCC(cid, phase, pct)
25      on deploy skills: write(deployment, ...) through Forgejo CI (§4)
26
27  // --- Result ---
28  return artifact(cid)  // rendered in ArtifactPanel; PCC narrates to completion

The shape to notice: propose/refine are pure (they never reach line 7); only an approval in the Refine Loop turns a PlannedStep into a real DispatchRequest and crosses into this algorithm (see §7.1). Because the entrypoint and the executor are each singular, there is exactly one place governance lives — no privileged client bypasses the broker.

A.4 AI-Provider Routing Policy

Model selection is policy, not scattered call sites. Research and ideation — the stages whose quality dominates venture outcomes — are pinned to a frontier Anthropic model at maximum thinking (see §2, Ideation); cheaper, faster tasks route to lighter tiers. We express this as a declarative contract resolved server-side, so no client can silently downgrade a reasoning-critical task.

TypeScript
37 lines
Copy
// AI-provider routing contract (illustrative; resolved server-side).
type TaskClass =
  | 'ideation'        // hypothesis generation + Red Queen critic (§2)
  | 'evaluation'      // EvaluatorService rubric / pairwise judge (§2)
  | 'research'        // STORM-style grounded synthesis (§3)
  | 'refine'          // Refine-Loop propose/refactor (§7)
  | 'codegen'         // pattern composition (§4, §8)
  | 'chat';           // conversational surface

type Thinking = 'off' | 'standard' | 'max';

interface RoutingRule {
  provider: 'anthropic';                    // frontier provider for reasoning-critical work
  model: string;                            // resolved to a concrete Anthropic model id (tiered by task)
  thinking: Thinking;
  maxThinkingTokens?: number;               // budget when thinking = 'max'
  temperature: number;
}

const ROUTING: Record<TaskClass, RoutingRule> = {
  ideation:   { provider: 'anthropic', model: 'claude-opus-4-8',  thinking: 'max',      temperature: 0.9 },
  evaluation: { provider: 'anthropic', model: 'claude-opus-4-8',  thinking: 'max',      temperature: 0.0 },
  research:   { provider: 'anthropic', model: 'claude-opus-4-8',  thinking: 'max',      temperature: 0.3 },
  refine:     { provider: 'anthropic', model: 'claude-opus-4-8',  thinking: 'standard', temperature: 0.4 },
  codegen:    { provider: 'anthropic', model: 'claude-sonnet-5',  thinking: 'standard', temperature: 0.2 },
  chat:       { provider: 'anthropic', model: 'claude-haiku-4-5', thinking: 'off',      temperature: 0.5 },
};

function resolveProvider(task: TaskClass): RoutingRule {
  const rule = ROUTING[task];
  // Invariant: ideation, evaluation, and research NEVER resolve below 'max'.
  if ((task === 'ideation' || task === 'evaluation' || task === 'research')
      && rule.thinking !== 'max') {
    throw new Error(`routing violation: ${task} must run at max thinking`);
  }
  return rule;
}

Pinning evaluation to max thinking at temperature 0 matters as much as pinning ideation: the fitness signal is an LLM-as-judge, and a stronger judge reduces (never eliminates) the position and length biases that make weak evaluators unreliable (see §2, §14). Routing is a governed input to dispatch, not a per-call convenience.

A.5 Phase-Ordered Build Guide

Build the cell before the intelligence; build the governed spine before the stages; build the stages in the order a venture traverses them. Each phase has an acceptance gate that must be green before the next begins.

1. Bootstrap the cell. Implement ProvisionSovereignCell (Algorithm 4.1, §4): namespace, isolated DB (the §A.2 schema), OAuth realm, domain + TLS, edge-SSR brand resolver, Forgejo CI, and the read-only federation edge. Gate: firstPaintRevealsNoAdverant passes and the seven independence criteria hold (see §4.1).
2. Chat + artifact shell. Mount UnifiedChatPanel/ChatSurfaceShell and ArtifactPanel with the UnifiedChatSurface model (ChannelKind/PanelMode/DockPosition), Socket.IO transport degrading to SSE after three failures (see §4.4). Gate: a message round-trips and an AG-UI event renders a live component.
3. UNO integration. Wire the dispatch client to POST /api/v1/dispatch, implement the five-gate broker (GatedDispatch, Algorithm 4.2), and stand up PCC + inspector keyed on correlationId; renderKbCard emits — for missing values (see §4.5). Gate: a denied dispatch shows a legible reason; an accepted one narrates through PCC. This phase makes Algorithm A.1 real.
4. Ideation (Catalyst). Implement EvaluatorService (0–100 over five 20-point dimensions, keep ≥ 60), the Bradley–Terry/Elo tournament, the Red Queen critic co-evolution, and OptimizerService as the mutation operator, all pinned to ideation/evaluation routing at max thinking (see §2, Ideation). Ground candidates against the Pattern Substrate for architectural precedent. Gate: surviving hypotheses clear the rubric floor and a human waitpoint.
5. Research (Thesis). Implement the STORM-style grounded pipeline over nexus-graphrag with citation-required synthesis (see §3, Research); unsupported claims surface as gaps, never smoothed. Gate: every asserted claim resolves to a retrieved source.
6. Deploy (Crucible). Compose artifacts from generalized patterns (see §8, the Pattern Substrate) — not blank-page synthesis — commit to the venture repo, and run build → trivy → cosign → OCI → k3s; scale WEB pods on HPA (3→15) [Ahmad 2024] and WORKER pods on KEDA over BullMQ queue depth (2→10) [Pilyai 2023] (see §4.2). Gate: the pipeline is green; rollback is a git revert on the same path.
7. Refine Loop (all stages). Wrap every stage in propose → refine → approve (see §7, the Refine Loop): persist each revision to plan_version, animate the visible diff, and make approve the only edge into Algorithm A.1. Gate: no consequential step is reachable without an approval; the propose/refine path writes no credit_ledger debit.
8. Pattern Substrate + IP firewall. Stand up nexus-reposwarm indexing into a graph store, emitting GeneralizedPattern records under the generalization transform, cross-tenant support ($\sigma(p)\ge k$) or consent gating, and the output-side reproduction check (see §8, the Pattern Substrate) [Edge 2024; Carlini 2021]. Gate: no concrete literal, secret, or tenant identifier is ever persisted or emitted.

The order is not cosmetic. Phases 1–3 give a sovereign, governed, observable cell that does nothing intelligent yet — but does it safely. Phases 4–8 add the intelligence inside that governance, so that at no point does a reasoning capability exist without the five gates, the human approval, and the IP firewall already standing between it and any irreversible act. A team that inverts this order builds power before control; a team that follows it builds a venture builder that is safe to hand a human idea.

---

14. Discussion, Limitations, Compliance & Roadmap

This is an architecture, methodology, and theory paper. We claim a design — four human-gated stages (Catalyst, Thesis, Crucible, Apex) each wrapped in the Refine Loop — and the contracts, algorithms, and formal models that make it buildable. We do not claim empirical, large-scale deployment results. No conversion rate, no build-time distribution, no win rate is asserted as measured; every quantitative figure elsewhere in the paper carries an [illustrative] tag or lives inside an explicitly-simulated model (the Monte-Carlo P&L of §10–§11). What follows is an honest account of where the design is load-bearing on assumptions, where it is exposed, and in what order it should be built.

14.1 Limitations

LLM-judge bias. The fitness signal in ideation — EvaluatorService, the immutable 0–100 rubric over five 20-point dimensions (see §2) — is an LLM-as-judge. That inherits the failure modes catalogued in the literature: position and order sensitivity, verbosity/length preference, self-preference, and stochastic instability across runs [Zheng 2023, Wang 2023]. Length bias is particularly corrosive for an ideation rubric, where a more verbose hypothesis can read as more "actionable" without being so [Dubois 2024]. The design mitigates rather than eliminates. First, the rubric is fixed and decomposed: five named dimensions, each independently scored, returning a structured EvaluatorResult with reasoning, strengths, weaknesses, and a hard keep = score ≥ 60 — this exposes why a score was assigned and lets a human reviewer at a waitpoint spot a length-inflated or off-rubric verdict. Second, pairwise comparisons average over both presentation orders, so position bias cancels to first order:

with a disagreement flag raised when the two orderings disagree on the winner. Third, the evaluator is pinned to a frontier Anthropic model at maximum thinking for ideation and research, reducing the variance that afflicts weaker judges. None of this makes the judge correct; it makes it auditable and keeps a human as the final arbiter of fitness.

Elo instability. Ideation selection uses a Bradley–Terry/Elo update [Bradley 1952, Elo 1978] over the tournament of candidate hypotheses (see §2). Pairwise rating systems are known to be sensitive to match scheduling, to violate transitivity when preferences are non-stationary, and to carry high variance under the small comparison budgets that a cost-bounded ideation loop can afford [Boubdir 2024]. We treat Elo as an ordinal selection heuristic, never as ground truth: it decides which candidates survive to the next generation, not whether a venture is good. Three guards follow. A minimum-comparison floor per candidate before its rating is trusted; a bounded K-factor so a single noisy match cannot dominate; and — decisively — coupling to the absolute rubric via the keep gate, so a candidate that wins its local matches but fails the 60-point floor is still culled. The Elo tournament ranks; the rubric and the human gate qualify.

Grounding gaps. The research stage (§3) and the K-card inspector are retrieval-grounded, and retrieval-augmented generation reduces but does not remove fabrication: recall is imperfect, indices go stale, and the generator can still confabulate over retrieved context [Lewis 2020, Gao 2023]. Self-critique and selective retrieval help but are themselves LLM-mediated [Asai 2023]. Two design commitments bound the blast radius. Missing values in K-cards render as —, never as a fabricated placeholder — the UI is forbidden from inventing a number. And research claims are citation-required: an unsupported assertion is surfaced as a gap for a human, not smoothed over. The residual risk is real and we name it: a confident, well-cited, and wrong synthesis remains possible, which is precisely why Thesis is human-gated.

Convergence assumptions of the Refine Loop. The Refine Loop's convergence argument (§7, the Refine Loop) models the propose→refine→approve operator as a contraction and invokes the Banach fixed-point theorem [Banach 1922]: if the refinement operator $T$ is Lipschitz with constant $L < 1$ on the relevant metric space,

then iterates converge to a unique fixed point. This is a modelling assumption, not a theorem about LLMs. We cannot prove that an LLM-driven refinement operator is globally contractive; empirically, iterative self-refinement improves outputs on many tasks but can plateau or even regress once a local optimum is reached [Madaan 2023], and equilibrium-style iteration is only well-behaved where the operator actually damps perturbations [Bai 2019]. The design therefore does not rely on contraction for safety. It relies on it for typical-case efficiency and installs a backstop: bounded iterations, a non-improvement halt, and the human gate as the true terminal condition (Algorithm 14.1). If the operator fails to contract, the loop stops and escalates rather than looping forever or drifting.

Plain Text
19 lines
Copy
Algorithm 14.1  Convergence-safe Refine termination (backstop)
Input:  x0 (initial artifact), T (refine operator), E (EvaluatorService),
        i_max (iteration cap), eps (min improvement), p (patience)
Output: x* (artifact to present at the human gate), status
 1: x <- x0 ;  s <- E(x).score ;  stall <- 0
 2: for i = 1 .. i_max do
 3:     x' <- T(x)                         # propose refinement
 4:     s' <- E(x').score                  # rubric fitness
 5:     if s' - s < eps then               # no meaningful gain
 6:         stall <- stall + 1
 7:     else
 8:         stall <- 0
 9:     end if
10:     if s' > s then x <- x' ; s <- s' end if   # keep only improvements
11:     if stall >= p then                 # not contracting -> stop early
12:         return (x, CONVERGED_OR_STALLED)
13:     end if
14: end for
15: return (x, ITERATION_CAP_REACHED)      # human gate decides regardless

The human waitpoint downstream of Algorithm 14.1 is not a formality: it is the safety property. Whether the loop converged, stalled, or hit its cap, a person approves, edits, or rejects before the artifact advances a stage.

14.2 Compliance and governance

GDPR and the psychometric wall. Any psychometric or persona modelling used to tune interaction (§6) is internal-only and synthetic: personas, never real named natural persons. No customer is profiled as an identified individual, no special-category inference is attached to a real identity, and the persona layer holds no directly-identifying data. This is data minimisation by construction, and it keeps the persona machinery outside the highest-risk GDPR surface. Real user data that does flow — prompts, artifacts, tenant content — is confined to the tenant's own cell.

Sovereignty and data residency. Each venture is a per-tenant cell: its own Kubernetes namespace, its own database, its own OAuth and domain, with only a federation edge to the shared control plane. This is the strong end of the tenant-isolation spectrum — dedicated-resource isolation rather than shared-schema pooling [Chong 2006, Ochei 2018], and it is the configuration that minimises cross-tenant noise and data-leak surface in multi-tenant RAG settings [Kumar 2026, Zheng 2021]. Residency is not merely a deployment fact; it is enforced at dispatch. Every action passes UNO's five-gate pre-execution broker — classification, data-residency, export-class, spend, safety — before a job is enqueued, so a residency or export-class violation is refused at the contract boundary rather than caught after the fact (§14.4 code pattern).

IP firewall and memorization risk. The Pattern Learning Substrate (§8) indexes prior Adverant platforms into GraphRAG and generates from generalized patterns only, behind an IP firewall — no verbatim proprietary or cross-customer source. The named risk here is memorization: neural models can memorize and, under adversarial prompting, regurgitate training data verbatim [Carlini 2021, Carlini 2023], including at production scale [Nasr 2023], with attendant copyright exposure [Karamolegkou 2023]. Because the substrate is a retrieval-and-generalization layer rather than a fine-tuned weight store, the tenant-source training channel is closed by construction — proprietary source never enters model weights. What remains is base-model pretraining memorization, a channel outside the substrate's control: it is narrowed by abstracting retrieved patterns before use, but not closed. Deduplication of the indexed corpus is a known and effective mitigation for extraction risk [Kandpal 2022] and is part of the firewall's hygiene. The honest position: the firewall is a policy-plus-architecture control, and its guarantee is only as strong as the abstraction step and the audit around it.

14.3 Threats to validity

Construct validity. The rubric is a proxy for "venture quality"; a high score is a hypothesis about a hypothesis, and the five dimensions may not span what makes a venture succeed. Internal validity. Judge and generator may share a model family, inflating self-preference correlation [Wang 2023]; the order-averaging and human gate are the countermeasures, not a cure. External validity. With no field deployment, generalization beyond the designed-for cases is unestablished — the strongest claim we make is buildability, not efficacy. Reproducibility. Pinning to frontier models means outputs shift as those models are updated; the contracts and algorithms are stable, the model behaviour underneath is not. Economic validity. The P&L is a correlated Monte-Carlo simulation (§10–§11), and every input is an assumption; it demonstrates a method and a sensitivity surface, not a forecast.

14.4 Compliance decision as a first-class contract

The residency/export guarantees above are only credible if refusal is typed and total. The broker returns a decision object, not a best-effort log line:

TypeScript
14 lines
Copy
type GateName =
  | 'classification' | 'data-residency'
  | 'export-class'   | 'spend' | 'safety';

interface ComplianceDecision {
  allowed: boolean;                 // false => job is never enqueued
  gate?: GateName;                  // the gate that refused (if denied)
  reason?: string;                  // human-readable, surfaced to the user
  residencyRegion?: string;         // resolved region the cell is pinned to
  correlationId: string;            // ties the decision to the DispatchRequest
}

// UNO enforces at the dispatch boundary, before BullMQ enqueue:
declare function broker(req: DispatchRequest): Promise<ComplianceDecision>;

A denied ComplianceDecision terminates the dispatch; nexus-workflows never sees the job. Compliance is thus not an audit performed after execution but a precondition of it.

14.5 Roadmap — phased build order

The dependency graph dictates the order. Human-gating is present from Phase 1 onward, consistent with mixed-initiative and human-in-the-loop planning practice [Horvitz 1999, Amershi 2019, Takerngsaksiri 2024].

• Phase 0 — Substrate. UNO dispatch (POST /api/v1/dispatch), the five-gate broker, BullMQ execution via nexus-workflows, CMA/GraphRAG memory, and the UnifiedChatPanel shell with the Progress Command Center. Nothing above works without this spine.
• Phase 1 — Catalyst + Refine Loop. EvaluatorService (the immutable rubric), the Elo tournament, OptimizerService as mutation operator, and the Refine-Loop backstop (Algorithm 14.1) with its first human waitpoint. This is the flagship contribution and should be provable end-to-end before anything downstream is built.
• Phase 2 — Thesis. The STORM-style grounded research pipeline (§3), citation-required synthesis, and K-card inspector rendering with the — rule.
• Phase 3 — Crucible. Sovereign white-label deploy: per-tenant cell provisioning, edge-SSR brand resolution, per-venture repo + Forgejo CI/CD (build→trivy→cosign→registry→k3s), and AG-UI streaming into the artifact pane.
• Phase 4 — Apex. Live gated product, HPA/KEDA autoscaling, and re-entry with versioned pivot (§5) so a live venture can loop back into ideation without losing lineage.
• Phase 5 — Pattern flywheel. Harden the Pattern Substrate (§8): abstraction, deduplication [Kandpal 2022], and IP-firewall audit, closing the loop from shipped ventures back into generalized reusable patterns.

Throughout, human-LLM collaborative planning and trust calibration remain open research surfaces we adopt rather than solve [He 2026, Chen 2025]: the gates are where a human stays in command, and their ergonomics — how much to show, when to interrupt, how to earn calibrated trust — are as much a part of the system as any algorithm here. We introduce no claim in this volume beyond those established earlier; we have instead marked the seams where the design is honest about what it assumes.

---

References

All 93 references were verified via dual-engine grounded research (Gemini grounded search + web search); each carries a resolvable arXiv id, DOI, or official URL. Inline citations use the bracketed label shown (e.g. [Zheng 2023]).

• [Afhami 2018] Reza Afhami; Shahin Mohammadi-Zarghan. The Big Five, Aesthetic Judgment Styles, and Art Interest. Europe's Journal of Psychology, 14(4), 764-775, 2018. doi:10.5964/ejop.v14i4.1479. doi.org
• [Ahmad 2024] Hussain Ahmad; Christoph Treude; Markus Wagner, et al.. Smart HPA: A Resource-Efficient Horizontal Pod Auto-scaler for Microservice Architectures. arXiv preprint, 2024. arXiv:2403.07909. arxiv.org
• [Amershi 2019] Saleema Amershi; Dan Weld; Mihaela Vorvoreanu, et al.. Guidelines for Human-AI Interaction. Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (CHI '19), pp. 1-13, 2019. doi:10.1145/3290605.3300233. dl.acm.org
• [Anthropic 2026a] Anthropic. Pricing — Claude Platform Documentation. Claude Platform Docs, 2026. platform.claude.com
• [Anthropic 2026b] Anthropic. Extended Thinking — Claude Platform Documentation. Claude Platform Docs, 2026. platform.claude.com
• [Asai 2023] Akari Asai; Zeqiu Wu; Yizhong Wang, et al.. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024 (arXiv preprint 2310.11511), 2023. arXiv:2310.11511. doi:10.48550/arXiv.2310.11511. arxiv.org
• [AXELOS 2017] AXELOS Limited. Managing Successful Projects with PRINCE2. The Stationery Office (TSO), London (6th edition), 2017. search.worldcat.org
• [Bai 2019] Shaojie Bai; J. Zico Kolter; Vladlen Koltun. Deep Equilibrium Models. Advances in Neural Information Processing Systems 32 (NeurIPS 2019), 2019. arXiv:1909.01377. arxiv.org
• [Banach 1922] Stefan Banach. Sur les opérations dans les ensembles abstraits et leur application aux équations intégrales. Fundamenta Mathematicae, vol. 3, pp. 133–181, 1922. doi:10.4064/fm-3-1-133-181. doi.org
• [Bansal 2017] Trapit Bansal; Jakub Pachocki; Szymon Sidor, et al.. Emergent Complexity via Multi-Agent Competition. arXiv preprint (ICLR 2018), 2017. arXiv:1710.03748. arxiv.org
• [Boubdir 2024] Meriem Boubdir; Edward Kim; Beyza Ermis, et al.. Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. Advances in Neural Information Processing Systems 37 (NeurIPS 2024), 2024. arXiv:2311.17295. arxiv.org
• [Boyle 1977] Phelim P. Boyle. Options: A Monte Carlo Approach. Journal of Financial Economics, 4(3), 323-338, 1977. doi:10.1016/0304-405X(77)90005-8. doi.org
• [Bradley 1952] Ralph Allan Bradley; Milton E. Terry. Rank Analysis of Incomplete Block Designs: I. The Method of Paired Comparisons. Biometrika, 1952. doi:10.1093/biomet/39.3-4.324. doi.org
• [Bradley 2023] Herbie Bradley; Andrew Dai; Hannah Teufel, et al.. Quality-Diversity through AI Feedback. arXiv preprint (ICLR 2024), 2023. arXiv:2310.13032. arxiv.org
• [Carlini 2019] Nicholas Carlini; Chang Liu; Úlfar Erlingsson, et al.. The Secret Sharer: Evaluating and Testing Unintended Memorization in Neural Networks. 28th USENIX Security Symposium (USENIX Security 2019), pp. 267-284, 2019. arXiv:1802.08232. arxiv.org
• [Carlini 2021] Nicholas Carlini; Florian Tramèr; Eric Wallace, et al.. Extracting Training Data from Large Language Models. 30th USENIX Security Symposium (USENIX Security 2021), pp. 2633-2650, 2021. arXiv:2012.07805. arxiv.org
• [Carlini 2023] Nicholas Carlini; Daphne Ippolito; Matthew Jagielski, et al.. Quantifying Memorization Across Neural Language Models. International Conference on Learning Representations (ICLR 2023), 2023. arXiv:2202.07646. arxiv.org
• [Chen 2021] Mark Chen; Jerry Tworek; Heewoo Jun, et al.. Evaluating Large Language Models Trained on Code. arXiv preprint (OpenAI), 2021. arXiv:2107.03374. doi:10.48550/arXiv.2107.03374. arxiv.org
• [Chen 2023] Xinyun Chen; Maxwell Lin; Nathanael Schärli, et al.. Teaching Large Language Models to Self-Debug. International Conference on Learning Representations (ICLR 2024), 2023. arXiv:2304.05128. doi:10.48550/arXiv.2304.05128. arxiv.org
• [Chen 2025] Shenghui Chen; Yunhao Yang; Kayla Boggess, et al.. Evaluating Human Trust in LLM-Based Planners: A Preliminary Study. arXiv preprint, 2025. arXiv:2502.20284. arxiv.org
• [Cheng 2025] Tuoyuan Cheng; Thibault Vatter; Thomas Nagler, et al.. Vine Copulas as Differentiable Computational Graphs. arXiv preprint arXiv:2506.13318, 2025. arXiv:2506.13318. arxiv.org
• [Chiang 2024] Wei-Lin Chiang; Lianmin Zheng; Ying Sheng, et al.. Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. International Conference on Machine Learning (ICML 2024), 2024. arXiv:2403.04132. doi:10.48550/arXiv.2403.04132. arxiv.org
• [Chong 2006] Frederick Chong; Gianpaolo Carraro; Roger Wolter. Multi-Tenant Data Architecture. Microsoft Corporation (MSDN Architecture Center whitepaper), 2006. learn.microsoft.com
• [Cialdini 1984] Robert B. Cialdini. Influence: The Psychology of Persuasion. William Morrow and Company, New York, 1984.
• [Dubois 2024] Yann Dubois; Balázs Galambosi; Percy Liang, et al.. Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators. arXiv preprint, 2024. arXiv:2404.04475. doi:10.48550/arXiv.2404.04475. arxiv.org
• [Edge 2024] Darren Edge; Ha Trinh; Newman Cheng, et al.. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv preprint (Microsoft Research), 2024. arXiv:2404.16130. doi:10.48550/arXiv.2404.16130. arxiv.org
• [Elliot 2014] Andrew J. Elliot; Markus A. Maier. Color Psychology: Effects of Perceiving Color on Psychological Functioning in Humans. Annual Review of Psychology, 65, 95-120, 2014. doi:10.1146/annurev-psych-010213-115035. doi.org
• [Elo 1978] Arpad E. Elo. The Rating of Chessplayers, Past and Present. Arco Publishing, New York (ISBN 9780668047210), 1978. archive.org
• [Embrechts 2002] Paul Embrechts; Alexander J. McNeil; Daniel Straumann. Correlation and Dependence in Risk Management: Properties and Pitfalls. Risk Management: Value at Risk and Beyond (ed. M.A.H. Dempster), Cambridge University Press, Ch. 7, 176-223, 2002. doi:10.1017/CBO9780511615337.008. doi.org
• [Fogg 2003] B. J. Fogg; Cathy Soohoo; David R. Danielson, et al.. How Do Users Evaluate the Credibility of Web Sites? A Study with Over 2,500 Participants. Proceedings of the 2003 Conference on Designing for User Experiences (DUX '03), 2003. doi:10.1145/997078.997097. dl.acm.org
• [Gandhi 2012] Anshul Gandhi; Mor Harchol-Balter; Ram Raghunathan, et al.. AutoScale: Dynamic, Robust Capacity Management for Multi-Tier Data Centers. ACM Transactions on Computer Systems (TOCS), 30(4), Article 14, 2012. doi:10.1145/2382553.2382556. dl.acm.org
• [Gao 2023] Yunfan Gao; Yun Xiong; Xinyu Gao, et al.. Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv preprint (submitted Dec 2023, rev. Mar 2024), 2023. arXiv:2312.10997. doi:10.48550/arXiv.2312.10997. arxiv.org
• [Gubbels 2023] Koos B. Gubbels; Jelmer Y. Ypma; Cornelis W. Oosterlee. Principal Component Copulas for Capital Modelling and Systemic Risk. arXiv:2312.13195; published in Computational Economics (2025), DOI 10.1007/s10614-025-11051-7, 2023. arXiv:2312.13195. doi:10.1007/s10614-025-11051-7. arxiv.org
• [Guo 2024] Zirui Guo; Lianghao Xia; Yanhua Yu, et al.. LightRAG: Simple and Fast Retrieval-Augmented Generation. arXiv preprint (accepted to EMNLP 2025), 2024. arXiv:2410.05779. doi:10.48550/arXiv.2410.05779. arxiv.org
• [Gupta 2004] Sunil Gupta; Donald R. Lehmann; Jennifer Ames Stuart. Valuing Customers. Journal of Marketing Research, 41(1), 7-18, 2004. doi:10.1509/jmkr.41.1.7.25084.
• [Gutierrez 2024] Bernal Jiménez Gutiérrez; Yiheng Shu; Yu Gu, et al.. HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. Advances in Neural Information Processing Systems (NeurIPS 2024), 2024. arXiv:2405.14831. doi:10.48550/arXiv.2405.14831. arxiv.org
• [He 2024] Xiaoxin He; Yijun Tian; Yifei Sun, et al.. G-Retriever: Retrieval-Augmented Generation for Textual Graph Understanding and Question Answering. Advances in Neural Information Processing Systems (NeurIPS 2024), 2024. arXiv:2402.07630. doi:10.48550/arXiv.2402.07630. arxiv.org
• [He 2026] Zeyu He; Hannah Kim; Dan Zhang, et al.. How to Steer Your Multi-Agent System: Human-LLM Collaborative Planning. ACM Conference on AI and Agentic Systems (ACM CAIS '26); arXiv preprint, 2026. arXiv:2605.23023. doi:10.1145/3786335.3813144. arxiv.org
• [Hong 2024] Sirui Hong; Mingchen Zhuge; Jonathan Chen, et al.. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. International Conference on Learning Representations (ICLR), 2024. arXiv:2308.00352. arxiv.org
• [Horvitz 1999] Eric Horvitz. Principles of Mixed-Initiative User Interfaces. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '99), pp. 159-166, 1999. doi:10.1145/302979.303030. dl.acm.org
• [Hughes 2024] Edward Hughes; Michael Dennis; Jack Parker-Holder, et al.. Open-Endedness is Essential for Artificial Superhuman Intelligence. ICML 2024 (Position paper), 2024. arXiv:2406.04268. arxiv.org
• [Hunter 2004] David R. Hunter. MM Algorithms for Generalized Bradley-Terry Models. The Annals of Statistics, 2004. doi:10.1214/aos/1079120141. doi.org
• [Jafarnejad 2019] Einollah Jafarnejad Ghomi; Amir Masoud Rahmani; Nooruldeen Nasih Qader. Applying queue theory for modeling of cloud computing: A systematic review. Concurrency and Computation: Practice and Experience, 31(17), 2019. doi:10.1002/cpe.5186. onlinelibrary.wiley.com
• [Jiang 2023] Zhengbao Jiang; Frank F. Xu; Luyu Gao, et al.. Active Retrieval Augmented Generation. Proceedings of EMNLP 2023 (Main Conference), 2023. arXiv:2305.06983. doi:10.48550/arXiv.2305.06983. aclanthology.org
• [Jiang 2024] Yucheng Jiang; Yijia Shao; Dekun Ma, et al.. Into the Unknown Unknowns: Engaged Human Learning through Participation in Language Model Agent Conversations. Proceedings of EMNLP 2024 (Main Conference), 2024. arXiv:2408.15232. doi:10.48550/arXiv.2408.15232. aclanthology.org
• [Jimenez 2024] Carlos E. Jimenez; John Yang; Alexander Wettig, et al.. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. International Conference on Learning Representations (ICLR), 2024. arXiv:2310.06770. doi:10.48550/arXiv.2310.06770. arxiv.org
• [Kandpal 2022] Nikhil Kandpal; Eric Wallace; Colin Raffel. Deduplicating Training Data Mitigates Privacy Risks in Language Models. Proceedings of the 39th International Conference on Machine Learning (ICML 2022), PMLR 162, pp. 10697-10707, 2022. arXiv:2202.06539. arxiv.org
• [Karamolegkou 2023] Antonia Karamolegkou; Jiaang Li; Li Zhou, et al.. Copyright Violations and Large Language Models. Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP 2023), pp. 7403-7412, 2023. arXiv:2310.13771. doi:10.18653/v1/2023.emnlp-main.458. aclanthology.org
• [Kumar 2026] R. Kumar. Silo, Pool, and Bridge for Multi-Tenant RAG: Measuring Isolation, Noisy-Neighbor Effects, and Cost in SaaS Microservices. International Journal of Emerging Trends in Computer Science and Information Technology (IJETCSIT), 7(1), 30-47, 2026. ijetcsit.org
• [Lewis 2020] Patrick Lewis; Ethan Perez; Aleksandra Piktus, et al.. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems (NeurIPS) 33, pp. 9459-9474, 2020. arXiv:2005.11401. doi:10.48550/arXiv.2005.11401. arxiv.org
• [Li 2000] David X. Li. On Default Correlation: A Copula Function Approach. The Journal of Fixed Income, 9(4), 43-54, 2000. doi:10.2139/ssrn.187289. doi.org
• [Li 2022] Yujia Li; David Choi; Junyoung Chung, et al.. Competition-Level Code Generation with AlphaCode. Science, vol. 378, no. 6624, pp. 1092-1097, 2022. arXiv:2203.07814. doi:10.1126/science.abq1158. arxiv.org
• [Li 2025] Jinghan Li; Zhicheng Sun; Yadong Mu. Closed-Loop Long-Horizon Robotic Planning via Equilibrium Sequence Modeling. International Conference on Machine Learning (ICML 2025), 2025. arXiv:2410.01440. arxiv.org
• [Liu 2023] Yang Liu; Dan Iter; Yichong Xu, et al.. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. Proceedings of EMNLP 2023, 2023. arXiv:2303.16634. doi:10.48550/arXiv.2303.16634. arxiv.org
• [Longstaff 2001] Francis A. Longstaff; Eduardo S. Schwartz. Valuing American Options by Simulation: A Simple Least-Squares Approach. The Review of Financial Studies, 14(1), 113-147, 2001. doi:10.1093/rfs/14.1.113. academic.oup.com
• [Madaan 2023] Aman Madaan; Niket Tandon; Prakhar Gupta, et al.. Self-Refine: Iterative Refinement with Self-Feedback. Advances in Neural Information Processing Systems 36 (NeurIPS 2023), 2023. arXiv:2303.17651. arxiv.org
• [Marston 1928] William Moulton Marston. Emotions of Normal People. Kegan Paul, Trench, Trubner & Co., London, 1928.
• [Mckeown 2008] Nick McKeown; Tom Anderson; Hari Balakrishnan, et al.. OpenFlow: Enabling Innovation in Campus Networks. ACM SIGCOMM Computer Communication Review, 38(2), 69-74, 2008. doi:10.1145/1355734.1355746. doi.org
• [Miller 1956] George A. Miller. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. Psychological Review, 63(2), 81-97, 1956. doi:10.1037/h0043158. doi.org
• [Mouret 2015] Jean-Baptiste Mouret; Jeff Clune. Illuminating search spaces by mapping elites. arXiv preprint, 2015. arXiv:1504.04909. arxiv.org
• [Nasr 2023] Milad Nasr; Nicholas Carlini; Jonathan Hayase, et al.. Scalable Extraction of Training Data from (Production) Language Models. arXiv preprint (also disclosed to OpenAI; ChatGPT divergence attack), 2023. arXiv:2311.17035. doi:10.48550/arXiv.2311.17035. arxiv.org
• [Nielsen 1994] Jakob Nielsen. Enhancing the Explanatory Power of Usability Heuristics. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '94), 152-158, 1994. doi:10.1145/191666.191729. dl.acm.org
• [Ochei 2018] Laud Charles Ochei; Julian M. Bass; Andrei Petrovski. Degrees of tenant isolation for cloud-hosted software services: a cross-case analysis. Journal of Cloud Computing (Springer), 7:22, 2018. doi:10.1186/s13677-018-0121-8. doi.org
• [Openendedlearningteam 2021] Open Ended Learning Team; Adam Stooke; Max Jaderberg, et al.. Open-Ended Learning Leads to Generally Capable Agents. arXiv preprint (DeepMind; XLand), 2021. arXiv:2107.12808. arxiv.org
• [Park 2023] Joon Sung Park; Joseph C. O'Brien; Carrie J. Cai, et al.. Generative Agents: Interactive Simulacra of Human Behavior. Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (UIST), 2023. arXiv:2304.03442. arxiv.org
• [Patil 2023] Shishir G. Patil; Tianjun Zhang; Xin Wang, et al.. Gorilla: Large Language Model Connected with Massive APIs. arXiv preprint (later NeurIPS 2024), 2023. arXiv:2305.15334. doi:10.5555/3737916.3741936. arxiv.org
• [Piepenbrock 2014] Cosima Piepenbrock; Susanne Mayr; Axel Buchner. Positive Display Polarity Is Particularly Advantageous for Small Character Sizes: Implications for Display Design. Human Factors, 56(5), 942-951, 2014. doi:10.1177/0018720813515509. doi.org
• [Pilyai 2023] Xavier Pilyai; Rafsanjani Nurul Irsyad; Ikhwan Nashir Zaini, et al.. Implementation and Benchmarking of Kubernetes Horizontal Pod Autoscaling Method to Event-Driven Messaging System. Advances on Broad-Band and Wireless Computing, Communication and Applications (BWCCA), Springer LNNS, 2023. doi:10.1007/978-3-031-46784-4_5. link.springer.com
• [Qin 2024] Yujia Qin; Shihao Liang; Yining Ye, et al.. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. International Conference on Learning Representations (ICLR), 2024. arXiv:2307.16789. arxiv.org
• [Ramperez 2021] Víctor Rampérez; Javier Soriano; David Lizcano, et al.. FLAS: A combination of proactive and reactive auto-scaling architecture for distributed services. Future Generation Computer Systems, vol. 118, pp. 56-72 (also arXiv:2510.20388), 2021. arXiv:2510.20388. arxiv.org
• [Reinecke 2014] Katharina Reinecke; Krzysztof Z. Gajos. Quantifying Visual Preferences Around the World. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '14), 11-20, 2014. doi:10.1145/2556288.2557052. dl.acm.org
• [Rudd 1996] Jim Rudd; Ken Stern; Scott Isensee. Low vs. high-fidelity prototyping debate. Interactions (ACM), Vol. 3, Issue 1, pp. 76-85, 1996. doi:10.1145/223500.223514. dl.acm.org
• [Schick 2023] Timo Schick; Jane Dwivedi-Yu; Roberto Dessì, et al.. Toolformer: Language Models Can Teach Themselves to Use Tools. Advances in Neural Information Processing Systems (NeurIPS) 36, 2023. arXiv:2302.04761. arxiv.org
• [Shao 2024] Yijia Shao; Yucheng Jiang; Theodore A. Kanell, et al.. Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models. Proceedings of NAACL-HLT 2024 (Long Papers), pp. 6252-6278, 2024. arXiv:2402.14207. doi:10.48550/arXiv.2402.14207. aclanthology.org
• [Shinn 2023] Noah Shinn; Federico Cassano; Edward Berman, et al.. Reflexion: Language Agents with Verbal Reinforcement Learning. Advances in Neural Information Processing Systems (NeurIPS), 2023. arXiv:2303.11366. arxiv.org
• [Shue 2012] David Shue; Michael J. Freedman; Anees Shaikh. Performance Isolation and Fairness for Multi-Tenant Cloud Storage. 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI '12), pp. 349-362, 2012. usenix.org
• [Si 2024] Chenglei Si; Yanzhe Zhang; Zhengyuan Yang, et al.. Design2Code: How Far Are We From Automating Front-End Engineering?. arXiv preprint (Stanford SALT-NLP), 2024. arXiv:2403.03163. arxiv.org
• [Sun 2024] Jiashuo Sun; Chengjin Xu; Lumingyuan Tang, et al.. Think-on-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph. International Conference on Learning Representations (ICLR 2024), 2024. arXiv:2307.07697. doi:10.48550/arXiv.2307.07697. arxiv.org
• [Sweller 1988] John Sweller. Cognitive Load During Problem Solving: Effects on Learning. Cognitive Science, 12(2), 257-285, 1988. doi:10.1207/s15516709cog1202_4. doi.org
• [Takerngsaksiri 2024] Wannita Takerngsaksiri; Jirat Pasuksmit; Patanamon Thongtanunam, et al.. Human-In-the-Loop Software Development Agents. arXiv preprint; accepted to IEEE/ACM 47th Int'l Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP 2025), 2024. arXiv:2411.12924. arxiv.org
• [Torres-Arias 2019] Santiago Torres-Arias; Hammad Afzali; Trishank Karthik Kuppusamy, et al.. in-toto: Providing farm-to-table guarantees for bits and bytes. 28th USENIX Security Symposium (USENIX Security 19), pp. 1393-1410, 2019. doi:10.5555/3361338.3361435. usenix.org
• [Tractinsky 2000] Noam Tractinsky; A. S. Katz; D. Ikar. What is beautiful is usable. Interacting with Computers, 13(2), 127-145, 2000. doi:10.1016/S0953-5438(00)00031-X. doi.org
• [Urgaonkar 2008] Bhuvan Urgaonkar; Prashant Shenoy; Abhishek Chandra, et al.. Agile Dynamic Provisioning of Multi-Tier Internet Applications. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 3(1), Article 1, 2008. doi:10.1145/1342171.1342172. dl.acm.org
• [Valdez 1994] Patricia Valdez; Albert Mehrabian. Effects of Color on Emotions. Journal of Experimental Psychology: General, 123(4), 394-409, 1994. doi:10.1037/0096-3445.123.4.394. doi.org
• [Wang 2019] Rui Wang; Joel Lehman; Jeff Clune, et al.. Paired Open-Ended Trailblazer (POET): Endlessly Generating Increasingly Complex and Diverse Learning Environments and Their Solutions. arXiv preprint (Uber AI Labs; presented at GECCO 2019), 2019. arXiv:1901.01753. arxiv.org
• [Wang 2023] Peiyi Wang; Lei Li; Liang Chen, et al.. Large Language Models are not Fair Evaluators. Proceedings of ACL 2024 (arXiv preprint 2023), 2023. arXiv:2305.17926. doi:10.48550/arXiv.2305.17926. arxiv.org
• [WCAG 2.1] W3C Web Accessibility Initiative. Web Content Accessibility Guidelines (WCAG) 2.1. W3C Recommendation, 05 June 2018, 2018. w3.org
• [Wu 2023] Qingyun Wu; Gagan Bansal; Jieyu Zhang, et al.. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv preprint (Microsoft Research), 2023. arXiv:2308.08155. arxiv.org
• [Xue 2025] Eric Xue; Ke Chen; Zeyi Huang, et al.. IMPROVE: Iterative Model Pipeline Refinement and Optimization Leveraging LLM Experts. arXiv preprint (submitted Feb 2025, rev. Sep 2025), 2025. arXiv:2502.18530. arxiv.org
• [Yang 2024] John Yang; Carlos E. Jimenez; Alexander Wettig, et al.. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. Advances in Neural Information Processing Systems (NeurIPS) 37, 2024. arXiv:2405.15793. arxiv.org
• [Yao 2023] Shunyu Yao; Jeffrey Zhao; Dian Yu, et al.. ReAct: Synergizing Reasoning and Acting in Language Models. International Conference on Learning Representations (ICLR), 2023. arXiv:2210.03629. arxiv.org
• [Zheng 2021] Chao Zheng; Qinghui Zhuang; Fei Guo. A Multi-Tenant Framework for Cloud Container Services. IEEE 41st International Conference on Distributed Computing Systems (ICDCS '21), pp. 359-369, 2021. arXiv:2103.13333. doi:10.1109/ICDCS51616.2021.00042. arxiv.org
• [Zheng 2023] Lianmin Zheng; Wei-Lin Chiang; Ying Sheng, et al.. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. Advances in Neural Information Processing Systems (NeurIPS 2023), Datasets and Benchmarks Track, 2023. arXiv:2306.05685. doi:10.48550/arXiv.2306.05685. arxiv.org