# StackBuilder — Compose a 4+1 architecture from assessed evidence

> https://stackbuilder.layer2c.com

StackBuilder composes reference architectures from Layer2C assessed evidence. It does not ask an LLM what vendors can do. The assessments are the source of truth; the model explains the recommendation, it never determines it.

The application is client-rendered. This file, and the machine-readable companions linked below, expose everything the instrument does as text so a crawler or retrieval agent can read it without running the app.

## What the instrument does

The engine is deterministic. It reads the graded assessments from Layer2C (vendor authority across the 4+1 Layer AI Infrastructure Model, scored with the Decision Authority Placement Model, DAPM) and Fourth Cloud (on-prem control-plane readiness, FC-0 through FC-4), composes vendors per layer, and computes two whole-design signals the per-layer grades cannot show:

- **Design Risk** — integration effort and where the seams sit: how many vendor seams the design carries, whether two competing base platforms got stitched together, and which critical feeds into the Reasoning Plane (2C) cross a vendor boundary the buyer must build.
- **Reasoning Dependency Index (RDI)** — how much autonomous runtime judgment the composed stack is built to exercise, reported beside who owns it (DAPM's question), never folded into it.

StackBuilder **never re-grades a vendor assessment.** The grades come from the assessment instruments and travel here unchanged. Every composed layer carries a citation back to the source assessment cell.

## Inputs it accepts

Two public entry points (see /stackbuilder-schema.json for the full contract):

- **compose** — supply an explicit `vendors` list (curated best-of-breed) or a `deployment` preference (`public` | `private` | `hybrid`), plus an `objective` (`capability` | `authority` | `balanced`). Optional: `pinned`, `excluded`, `assign` (place a vendor at a layer), `anchor` (pin the coherence tie-break for a reproducible result).
- **wizard** — outcome-driven: pick business `outcomes` and `painPoints`; the engine maps them to priority 4+1 layers and an authority lean, then composes. It makes the buyer place their authority; it does not loan composition judgment.

## Deterministic composition rules

- Capability and authority are quoted from the graded assessments, never generated.
- Authority is inherited from the contributing vendor's cell. The only thing the buyer retains by composing is the stitching, the integration seam that exists whenever more than one vendor contributes.
- Affinity-lock: a composition adopts at most one base platform per deployment world; specialists supplement it. Two competing platforms are never stitched together, and a design that ends up with two is flagged.
- The critical feeds into the Reasoning Plane (1A→2C governance, 2A→2C telemetry, 2B→2C SLA) are where strong-on-paper capability is only realized by building integration. When those layers are different vendors, the feed crosses a seam the buyer owns.
- An explicit placement is refused, never faked, if the vendor is a gap at that layer. The engine cannot manufacture capability that is not graded.
- A gap layer becomes the buyer's: authority Retained, and the gap stays visible rather than filled in by model confidence.

## How it reasons

- **Determinism.** Given identical inputs, StackBuilder produces identical architectures. The coherence `anchor` pins tie-breaks; supply it and a composition reproduces exactly.
- **One vendor per layer.** Each layer gets exactly one contributor, the best graded pick under the objective. Vendors do not co-satisfy a layer; a specialist supplements the base only where it is the pick.
- **Ties** break toward the anchor (coherence), then whole-stack coverage, then retained authority. The authority objective leads with retained authority among adequate vendors.
- **The buyer can override.** `pinned` prefers a vendor, `excluded` vetoes one (a veto beats a pin), `assign` places a vendor at a layer. An assign is refused if that vendor is a gap there.
- **Provenance.** Every layer cites its source assessment cell, and the reference reports extend that to the hands-on Lab that validated the vendor at that layer, where one exists. Grades are never altered.

## Reproduce and audit

- **Determinism.** Identical inputs including an explicit `anchor` produce a byte-identical composition. Without an anchor, tie-breaks among equally-graded leaders are randomized; pass the anchor from an output back in to reproduce it exactly. The anchor only breaks ties, never overriding a real grade difference.
- **Exact logic.** The pick algorithm per objective, the affinity-lock, and the precise Design Risk and RDI formulas are published at /stackbuilder-reproducibility.json, so another agent can reconstruct a stack and verify every derived signal rather than trusting the output.
- **Substitutions.** Swapping a vendor at one layer can change adjacent-layer signals: it can add or remove an integration seam, create or clear a cross-vendor feed into the Reasoning Plane, or flip a platform between base and specialist. The per-layer grade does not change; the whole-design signals can.
- **Saved roadmaps** (account required) store the inputs plus the resolved anchor, not the composed output or a grade version. They re-derive from current grades on reopen, so a re-graded assessment flows through. Reproducible by input, not frozen by version. The assessment version each vendor is composed against is listed in /components.json.

## Outputs it produces

A composed stack (one vendor per layer, with inherited authority and a citation), plus: the two whole-design signals (Design Risk, RDI), the retained/ceded control split, the integration seams and any competing-platform flag, the cross-vendor feeds into the Reasoning Plane, the Fourth Cloud sustainability read for contributors that have one, unresolved gaps the buyer owns, and any refused placements. Full shape in /stackbuilder-schema.json.

## Supported components

- **Layers:** the 8 layers of the 4+1 model (Layer 0 Compute, 1A Storage, 1B Retrieval, 1C Pipelines, 2A Orchestration, 2B Runtime, 2C Reasoning, Layer 3 Applications).
- **Vendors:** the assessed 4+1 vendors, each classed as a base **platform** (adopt one whole ecosystem; one per world) or a composable **specialist** (supplements a base at its strongest layers). The full machine-readable list, with each vendor's deployment, Fourth-Cloud flag, and per-layer status, is at /components.json.

## Discovery files (machine-readable)

| File | URL | Contents |
|---|---|---|
| Composition schema | https://stackbuilder.layer2c.com/stackbuilder-schema.json | Inputs, deterministic composition rules, and the full output shape (Design Risk, RDI, per-layer authority, provenance) |
| Reproducibility spec | https://stackbuilder.layer2c.com/stackbuilder-reproducibility.json | The exact composition and scoring logic: pick algorithm per objective, anchor/tie handling, affinity-lock, and the precise Design Risk and RDI formulas — enough to reconstruct a stack and verify every signal |
| Components list | https://stackbuilder.layer2c.com/components.json | Every assessed vendor with kind, deployment, Fourth-Cloud flag, 4+1 layer-status row, and the canon assessment version/date it is composed against; the 8 layers |
| Reference reports | https://stackbuilder.layer2c.com/example-composition.json | Two real, unmodified engine outputs (request + response) with a reasoning view: a single-hyperscaler stack and a best-of-breed hybrid |

The reference reports show the trade directly. The single-hyperscaler stack covers all eight layers with zero seams and the lowest Design Risk, but every layer is Ceded. The best-of-breed hybrid is strong per layer, yet the engine flags two competing platform bases, three integration seams, and three cross-vendor feeds into the Reasoning Plane. High Design Risk is a property of the composition, not of any one grade.

## Governed chat

Governed chat (vCTOA): ask the research system at any property; every answer carries typed evidence, versions, and limits. Machine door + policy: https://virtual-cto-api-1006606217023.us-east4.run.app/api/v1/vctoa/registry

## Part of the Layer2C research system

Layer2C assesses authority. Fourth Cloud assesses operating-model readiness. Labs validates where authority holds through scoped builds. StackBuilder composes architectures from the assessed evidence. The 4+1 and Fourth Cloud models share the DAPM axis and a reasoning-plane keystone but are deliberately not isomorphic.

| Property | URL | Role |
|---|---|---|
| Layer2C (canon) | https://layer2c.com | 4+1 vendor authority assessments, scored with DAPM |
| Fourth Cloud | https://cloud.layer2c.com | On-prem control-plane readiness, FC-0 through FC-4 |
| Layer2C Labs | https://labs.layer2c.com | Validates where authority holds, through scoped real-hardware builds |
| StackBuilder (this site) | https://stackbuilder.layer2c.com | Composes architectures from the assessed evidence |
| System map | https://layer2c.com/system | How the four properties relate |

## Source data

- https://layer2c.com/llms.txt — Layer2C assessment index (the 4+1 evidence StackBuilder composes from)
- https://cloud.layer2c.com/llms.txt — Fourth Cloud assessment index

## Independence

Layer2C is an independent architectural research system. Assessments are opinionated analyses, not certifications, paid rankings, procurement recommendations, or permanent conclusions. StackBuilder is an educational instrument that names the trade to sharpen a conversation with an architect, not to replace one.

Authored by The CTO Advisor LLC · https://thectoadvisor.com