StackBuilder deterministically composes 4+1 reference architectures from current Layer2C
assessment grades. It never re-grades evidence: capability and authority are quoted from the
canon, never generated. Given identical inputs, it produces identical architectures.
Purpose
The application layer of the Layer2C research system. It consumes assessed evidence, it does
not create it: the 4+1 vendor-authority grades from layer2c.com and Fourth Cloud readiness
from cloud.layer2c.com. It composes vendors layer by layer; the model narrates the result, it
never determines it. It is an educational instrument that names the trade, not a certification
or a vendor ranking.
Inputs
An explicit vendor set (curated best-of-breed) or a deployment preference: public, private, or hybrid.
An objective: capability, authority, or balanced.
Optional constraints: pinned (prefer a vendor), excluded (veto a vendor), assign (place a vendor at a layer), anchor (pin tie-breaks for a reproducible result).
Deterministic composition rules
Never alter assessment grades; never infer unsupported capability.
One vendor contributes each of the 8 layers, the best graded pick under the objective; a specialist supplements a base platform only where it is the pick. At most one base platform per deployment world (affinity-lock); two competing platforms are never stitched together.
Authority is inherited from the contributing vendor; the buyer retains the integration stitching across vendors.
An explicit placement is refused if the vendor is a gap there. A gap layer stays visible as the buyer's to own.
Prefer retained authority when the authority objective is requested. Ties break toward the coherence anchor, then whole-stack coverage, then retained authority.
Outputs
A composed stack: one vendor per layer with its capability status, inherited authority (DAPM: Retained, Delegated, or Ceded), and a citation to the source assessment cell.
Design Risk: the integration seams, a competing-platform flag, and the critical feeds into the Reasoning Plane (2C) that cross a vendor boundary the buyer must build.
Reasoning Dependency Index (RDI): how much autonomy the stack is built to exercise, reported beside who owns it.
The retained/ceded control split, unresolved gaps the buyer owns, and any refused placements.
Provenance
Every composed layer cites its source assessment on layer2c.com. The reference reports extend
that to the hands-on Lab (labs.layer2c.com) that validated the vendor at that layer where one
exists. Grades are never modified here.
Reproducibility
Identical inputs including an explicit anchor produce a byte-identical composition; without an
anchor, tie-breaks among equally-graded leaders are randomized, so pass the anchor from an
output back in to reproduce it. The exact pick algorithm, affinity-lock, and Design Risk and
RDI formulas are published at /stackbuilder-reproducibility.json, so another agent can
reconstruct a stack and verify every signal. Saved roadmaps (account required) store the
inputs plus the resolved anchor and re-derive from current grades, so an assessment update
flows through; they are reproducible by input, not frozen by version.
Current evidence source
The graded 4+1 vendor assessments at layer2c.com and the Fourth Cloud readiness assessments at
cloud.layer2c.com. The available components (vendors and layers) are listed at /components.json.
Example composition
Request: {"vendors":["aws"],"objective":"capability"}. Result: AWS covers all eight layers,
coverage 8/8, zero integration seams, Design Risk low, but all eight layers are Ceded, so no
authority is retained, and RDI is high (the stack acts on a moderate reasoning plane it does
not own). The full report, with the assessment-and-lab evidence chain per layer, is at
/example-composition.json.
Machine-readable documentation
Compose a complete 4+1 architecture.
No single vendor delivers a complete stack, and there is no turnkey way to assemble one. Stack Builder composes across vendors to show you the trade — the control you cede, the gaps you own, the integration effort you carry — grounded in the graded 4+1 and Fourth Cloud assessments.
It is built to educate, not prescribe: to sharpen your decision and the conversation you have with an architect, not to hand you a design to go build unadvised. The patterns below teach the shapes; the requirements wizard composes for your situation.
How StackBuilder works
StackBuilder does not ask a language model what vendors can do. It composes from assessed evidence, then uses the model to explain the recommendation.
The composition is deterministic. It reads the graded 4+1 and Fourth Cloud assessments, composes a vendor for each layer, and computes two signals: Design Risk, the integration effort you carry, and the Reasoning Dependency Index (RDI), how much autonomous judgment the composed stack is built to exercise. The model writes the narration. It never re-grades a vendor and it never invents a capability.
Recommendations are bounded by the available assessments and the methodology. Where the evidence is missing, StackBuilder leaves the gap visible rather than filling it in with model confidence.
It sharpens your decision and the conversation you have with an architect. It does not replace one.
Start with a pattern — illustrative, not prescriptive
Start with a cloud pattern, describe your requirements, or place vendors at individual layers. The resulting stack shows the integration effort and gaps you own. Use it to inform the conversation with an architect.
Part of the Layer2C research system
StackBuilder is one instrument in a four-part system. System map →