B4Mv3 Blueprint Architecture Proposal (v2)

Date: April 10, 2026 Authors: Ken Wallace (with Claude architecture agents) For the quorum: Nao, Jude, Ken, Victor, James, Isao, Matt, Julie, Stormy Status: Revised proposal incorporating Isao's feedback + Stormy's Polaris audit + git history validation. Related: PR #7673 (strawman), Package Proposal, Blueprint v1, Stormy's Quorum Response, Erik's strategy update of 2026-04-04. Changes from v1: Pared back over-specified mechanics. Migration-style versioning. Social contract first, technical guardrails later. Data-driven package vs blueprint split validated against 6 months of git history from both Lumina5 and Polaris.

Editor's note. This is Ken's formal response to Erik's call in the April 4 strategy update for an architectural plan to deliver B4M V3 — the compositional refactor that lets us stand up IonQ, LibreOncology, LiftPort/Mars Society, and games on the same spine. The quorum named in the front matter is the group Erik tasked. This document is the architectural through-line: less new code, more reusable knowledge.

The idea in one paragraph

Every B4M product is built from the same architectural DNA: Data Lake, GenAI Window, ReACT Agents, Custom Tools, Enterprise Shell. Today we already share this DNA by having Claude Code study one repo's implementation and generate an adapted version for another. This proposal formalizes that workflow. A small set of true shared packages handles security and types. Everything else is a blueprint — a living reference implementation plus architectural guidance that Claude Code (or a human) uses to generate product-specific code. Products own their code. Blueprints own the knowledge.

Why not just packages?

When we port features between Polaris and Lumina5 today, we don't import a shared package. We:

Start in the repo with the working feature
Have Claude Code create an implementation plan based on that code
Bring that plan to the other repo
Claude Code generates an adapted implementation that fits the target project

This is already a blueprint pattern. We just haven't named it.

Packages create problems when products need to diverge:

IonQ's quest loop will differ from Polaris's
LibreOncology's data lake will have different chunking strategies
Each product remolds the feature to fit — and then we lose package updates

Blueprints accept this reality instead of fighting it. The shared artifact is the knowledge of how to build it well, not a single codebase everyone imports.

The architecture

Strategic principle

From Isao: “Your strength is not in existing code, it is in implementation, agility, and experience. Minimize shared code dependencies between live products and customers. Share patterns first, then code only when divergence is clearly suboptimal.”

This principle drives the entire architecture: the default is independence, not sharing. Only package what is truly stable infrastructure where divergence would be a bug. Everything else is knowledge (blueprints) that teams use to build — and then own — their implementations. IonQ should be designed top-down from customer requirements, not bottom-up from shared platform capabilities.

Two layers, validated by git history

We audited 6 months of git history across both Lumina5 and Polaris to determine what's truly stable infrastructure (package) vs actively evolving business logic (blueprint). The data — not assumptions — drives this split.

Layer 1: True packages (stable, shared — rarely change)

Package	Why It's a Package	Git Evidence
`@b4m/core`	Types, Zod schemas, enums, error classes. The lingua franca.	Shared types are the foundation. Must never diverge.
`@b4m/auth`	Passport, JWT, MFA, API keys, rate limiting. Security must be identical everywhere.	Security code is structurally identical in both repos. Divergence here is a vulnerability.
`@b4m/infra`	SST factory functions, secret manifests, observability defaults. Infrastructure plumbing.	SST patterns are the same. Products customize their wiring, not the factories.
`@b4m/observability`	Structured logging, correlation IDs, health checks.	Must be consistent for cross-product debugging.
`@b4m/db-core`	BaseRepository, connection management, Mongoose plugins.	72 Polaris repos + 139 Lumina5 repos extend the same BaseRepository. The abstraction is stable.
`@b4m/fab-pipeline`	SmartChunker, EmbeddingFactory, BaseSearchIndex. The stable core of document processing.	Lumina5: 3 commits (bug fixes only). Polaris: 0 commits. This code is frozen. Both repos already share it via `@bike4mind/utils`.
`@b4m/llm-adapters`	Raw LLM provider interfaces only — `ICompletionBackend`, `getLlmByModel()`. The package provides the mechanism to call any supported model. The blueprint decides which model to call, when, and with what context.	Lumina5: 7 commits (SRE tuning, model config). Provider adapters are operational infrastructure. Both repos route through the same backends.
`@b4m/blueprints`	Blueprint lifecycle tooling — Claude Code skills for creating, amending, consuming, and tracking blueprints.	The package that makes the whole blueprint system work.

These are 8 core packages, plus 2 provisional packages (mementos, artifacts) that may graduate to blueprints if a second product customizes them. They are proven stable by git history — either frozen (0–3 commits in 6 months) or only changing for operational reasons (SRE fixes, model config). Security fixes auto-propagate. This is the floor.

Layer 2: Blueprints (actively evolving, product-specific)

Blueprints are not packages, and they are not tied to any single project's code. They are architectural knowledge that exists above any implementation:

An architecture doc (what this capability IS — the concepts, patterns, decisions, trade-offs)
Shared interfaces (TypeScript types that define the contract)
A generation guide (how Claude Code should adapt this for a new product)

Blueprints do NOT contain or reference a “canonical” implementation. Instead, every product that implements a blueprint registers in its blueprint-manifest.json. When a new product wants to add a capability:

Read the blueprint — understand what the capability is, what patterns to follow, what interfaces to satisfy
Discover existing implementations — search blueprint-manifest.json across repos to find projects that have already implemented this blueprint
Study the closest match — Claude Code reads the implementation most similar to what this project needs
Generate an adapted version — Claude Code generates code informed by the blueprint knowledge AND the real-world examples

No single project is “the reference.” Lumina5, Polaris, and IonQ are all examples of how to implement the blueprint. The blueprint itself is the source of truth for what to build. The implementations are examples of how others built it. Over time, the best patterns from any project's implementation can be captured back into the blueprint as amendments.

Blueprint	Why It's a Blueprint	Git Evidence
Quest loop	The agentic ReACT loop, tool calling, streaming, multi-turn management.	Polaris: 124 commits to `questStart.ts` (2,290 lines). Lumina5: 9 commits to LLM services. Completely different architectures — parallel tool loading, `_isMcpTool` pattern, throttled streaming, subscription gating, context overflow retry. These are not configuration differences; they're architectural differences.
Data lake service	Data lake CRUD, wizard, taxonomy, lifecycle management. (NOT the FAB chunking pipeline — that's a package.)	Polaris: 18 commits adding 11-phase wizard, folder taxonomy, archive/unarchive lifecycle, segment tags, content sampling. Lumina5: 1 commit (refactor only). Polaris diverged heavily with enterprise-specific features.
LLM orchestration	How the LLM is used — token budgeting, context management, model routing strategy, system prompt injection. (NOT the raw adapters — those are a package.)	Polaris: 10 commits adding org-wide system prompts, market model GenAI tools factory, deep research config, thinking support. These are product-specific features layered on top of the adapter layer.
Realtime / WebSocket	Real-time communication, streaming, event delivery.	Lumina5: 16 commits — the most active area. CLI streaming, Jupyter notebook execution, Tavern game relay, voice sessions. All product-specific features.
Enterprise config	RBAC rules, trial routes, feature catalogs, analytics event types. (NOT the engines — CASL evaluator, trial middleware are packages via `@b4m/auth`.)	Polaris: 50+ features, 8 roles, 60+ event types — all Polaris-specific names. Lumina5 has different features, different roles. The evaluation engine is shared; the configuration is always product-specific.
Tools (implementations)	Domain-specific tool code.	Polaris: 112 tools across 10+ practice areas. Lumina5: 40+ tools in different categories. Only the tool framework (registry, execution) is shared. Implementations are always product code.
Mementos	Memory/context system (hot/warm/cold tiers).	Lumina5: 1 commit (dormant). Polaris: doesn't have it. Currently a package candidate since only Lumina5 has it. Becomes a blueprint IF a second product customizes it. Start as package, graduate to blueprint if needed.
Artifacts	Artifact model + rendering.	Lumina5: 1 commit (dormant). Polaris: minimal. Same logic as mementos — package for now, blueprint if divergence happens.

The decision rule

Package it if: git history shows fewer than 5 commits in 6 months across both repos, AND the code is structurally identical, AND divergence would be a bug.
Blueprint it if: git history shows active product-specific evolution (>10 commits with product-customized features), OR the implementations have already diverged architecturally.
5–10 commits (gray zone): use the “AND divergence would be a bug” qualifier as the tiebreaker. If the changes are operational/SRE (same logic, just tuning), it's still a package. If the changes are product-specific features, it's a blueprint.
Start as package, graduate to blueprint if: only one product has the capability today (mementos, artifacts). Package it now. If a second product customizes it significantly, convert to blueprint. This graduation applies to ALL packages, not just the two called out.
Re-evaluate quarterly or when a capability receives >5 product-specific commits in a quarter. The /blueprint-status skill could surface packages with increasing divergence as candidates for graduation.

The hard numbers

Area	Lumina5 commits (6mo)	Polaris commits (6mo)	Same code?	Classification
FAB pipeline (chunk/vectorize/search)	3 (bug fixes)	0	Yes	Package
Data lake service (CRUD/wizard/taxonomy)	1 (refactor)	18 (heavy customization)	No	Blueprint
LLM adapters (provider interfaces)	7 (SRE tuning)	Same adapters	Yes	Package
LLM orchestration (how LLM is used)	9 (active)	124 (via questStart.ts)	No	Blueprint
Quest loop	Part of LLM services	124 commits, 2,290 lines	No	Blueprint
WebSocket/realtime	16 (very active)	Different patterns	No	Blueprint
Mementos	1 (dormant)	Doesn't exist	N/A	Package (for now)
Artifacts	1 (dormant)	Minimal	Likely yes	Package (for now)
Enterprise engines (CASL, trial gate)	Stable	Stable	Yes	Package (via @b4m/auth)
Enterprise config (rules, features, events)	Product-specific	Product-specific	No	Blueprint
Queue handlers	230 commits	326 commits	Almost entirely disjoint	Product-specific (only 4 of ~30 handlers shared)

Note on queue handlers: queue handlers are product-specific code that implements blueprint capabilities — they are part of each blueprint's generated implementation, not a separate blueprint. When /apply-blueprint quest generates a quest loop, it also generates the associated queue handler.

Blueprints as migrations

Inspired by Isao's database migration analogy.

A blueprint isn't a monolithic document — it's a base plus amendments, just like database migrations. Products apply the base, selectively apply amendments, and add their own product-specific customizations.

blueprints/data-lake/
├── base.md                          # What a data lake IS — concepts, patterns, decisions
├── interfaces.ts                    # Shared TypeScript interfaces (the contract)
├── test-patterns.md                 # Key behavioral assertions (critical path tests, not a full TCK)
├── 0001_taxonomy_inference.md       # Amendment: auto-tagging from content
├── 0002_duplicate_detection.md      # Amendment: similarity-based dedup
├── 0003_batch_ingestion.md          # Amendment: bulk file import
└── ARCHITECTURE.md                  # Why decisions were made, trade-offs, alternatives considered

The test-patterns.md file describes key behavioral assertions that any implementation should satisfy (e.g., “ingested files must be searchable within 60 seconds,” “search results must respect org-level permissions”). /apply-blueprint generates corresponding test stubs alongside the implementation code.

Notably: no reference/ directory. Blueprints don't point to a specific project's code. When you /apply-blueprint data-lake, the skill can optionally discover existing implementations in locally accessible repos and use the closest as an example — or generate entirely from the blueprint knowledge if no references are available.

Each product tracks what they've applied via blueprint-manifest.json (managed by the @b4m/blueprints package — see below):

products/ionq-agi/
├── blueprint-manifest.json          # Machine-readable state (managed by skills)
├── src/services/data-lake/          # Generated + customized implementation
└── blueprints-local/
    └── data-lake/
        └── custom_quantum_parsing.md  # IonQ-specific amendment

Blueprint dependencies

Some blueprints depend on others. The base.md declares this:

<!-- blueprints/quest/base.md -->
# Quest Loop Blueprint

## Dependencies
- data-lake/base (quest needs to search the data lake)
- llm-orchestration/base (quest needs LLM orchestration for the agentic loop)

The @b4m/blueprints package resolves dependencies automatically — the /apply-blueprint skill checks the manifest before generating and tells you what's missing.

`@b4m/blueprints` — the blueprint lifecycle package

This is the tooling that makes the entire blueprint system work. It's a true shared package (Layer 1) that provides Claude Code skills for the full blueprint lifecycle.

Why a package?

If blueprints are the standard way of creating and sharing capabilities, then the workflow around blueprints needs to be consistent and reliable across all products. Developers shouldn't have to think about manifest formats, dependency resolution, or amendment numbering — Claude Code handles all of that through skills.

The manifest (`blueprint-manifest.json`)

Every product has a manifest managed by the skills. Developers never edit this directly — it's Claude Code's source of truth.

{
  "product": "ionq-agi",
  "applied": [
    {
      "blueprint": "data-lake",
      "entry": "base",
      "blueprintHash": "a3f8c2d",
      "appliedAt": "2026-04-15T10:30:00Z",
      "generatedFiles": ["src/services/data-lake/"],
      "notes": "Generated with quantum paper parsing customization"
    },
    {
      "blueprint": "data-lake",
      "entry": "0001_taxonomy_inference",
      "blueprintHash": "b7e1d4f",
      "appliedAt": "2026-04-15T10:45:00Z",
      "generatedFiles": ["src/services/data-lake/taxonomy.ts"]
    }
  ],
  "skipped": [
    {
      "blueprint": "data-lake",
      "entry": "0002_duplicate_detection",
      "reason": "Not needed for quantum papers",
      "evaluatedAt": "2026-04-15T11:00:00Z"
    }
  ]
}

Claude Code skills

The package provides 4 skills that handle the entire blueprint lifecycle:

Skill	Purpose	When to use
`/create-blueprint`	Extract architectural knowledge into a new blueprint	A capability exists and a second product needs it
`/amend-blueprint`	Share a fix, feature, or improvement back to the blueprint	You've fixed a bug or added a feature others could benefit from
`/apply-blueprint`	Apply any blueprint entry to your project (base, amendment, or fix)	Your product needs a capability, an amendment, or a fix advisory
`/blueprint-status`	Check what's applied, what's available, what fixes are pending	Anytime — situational awareness

There is one skill for consuming (/apply-blueprint) and one for contributing (/amend-blueprint). Both handle all cases — features, fixes, base blueprints — through a single entry point. Claude Code determines the details automatically.

`/create-blueprint` — extract a blueprint from existing code

When to use: a capability exists in one or more products and needs to be formalized as shared architectural knowledge.

What it does:

Asks which capability to blueprint (or auto-detects from the code you point it at)
Studies existing implementation(s) to understand the capability — but extracts knowledge, not code
Generates base.md — what this capability IS, the patterns, decisions, trade-offs
Extracts interfaces.ts — TypeScript interfaces that define the contract
Generates ARCHITECTURE.md — decision records, why things are the way they are
Sets up the directory structure under blueprints/

The resulting blueprint describes the capability abstractly. It does not contain or reference the source code — the source code was just input for understanding.

`/amend-blueprint` — share a fix, feature, or improvement back to the blueprint

When to use: you've fixed a bug, added a feature, or improved a pattern in your project and want to share it so other projects can benefit.

What it does:

Reads the fix/feature diff in your project (or you describe it)
Reads the existing blueprint and its amendments
Determines the type of change automatically:
- Amendment (feature): A new capability that other projects might want. Numbered sequentially (0001, 0002, etc.)
- Amendment (FIX): A bug fix that other implementations might need. Prefixed with FIX_ and tagged with severity.
- Blueprint update: The fix reveals that the blueprint itself was describing the wrong pattern. Claude Code updates base.md or ARCHITECTURE.md directly so future implementations don't make this mistake.
Generates the appropriate artifact (amendment file or blueprint edit)
Declares any new dependencies if applicable

The developer doesn't decide what type it is — Claude Code reads the change, compares it to the blueprint, and determines: “Is this a new feature other projects might want? A fix for a specific bug? Or is the blueprint itself wrong?”

`/apply-blueprint` — the single entry point for consuming blueprints

When to use: your product needs a capability, or you want to check for updates/fixes on a blueprint you've already applied.

Just run /apply-blueprint <name>. You don't need to know amendment names, fix numbers, or what's available. The skill checks your manifest, figures out where you are, and guides you through what's next.

What it does:

Checks your blueprint-manifest.json to see if this blueprint is already applied
If not applied: checks dependencies, optionally discovers existing implementations in locally accessible repos (or generates from blueprint knowledge alone if none available)
If already applied: compares blueprintHash in your manifest against the current blueprint. Detects three kinds of changes:
- Blueprint itself was updated (base.md changed) — Claude Code diffs what changed and determines if your implementation needs updating
- New fixes available — auto-evaluates and applies, adapts, or skips each one
- New amendments available — presents them as options
Fixes auto-evaluate — Claude Code analyzes your code and applies, adapts, or skips each fix automatically with documented reasoning. No manual triage.
Amendments are presented as options — you pick which ones you want
Updates manifest (including new blueprintHash) with everything that was applied or skipped
Runs type checks against shared interfaces

Important: generated code is a starting point. It must be reviewed by a human and committed like any handwritten code.

`/blueprint-status` — check your product's blueprint state

When to use: to see what's applied, what's available, and what fix advisories are pending.

What it does:

Reads your blueprint-manifest.json
Compares against the blueprint source — the central location where blueprint files (base.md, amendments, fixes, interfaces.ts) are stored
Detects: new blueprints available, new amendments/fixes since your last application, blueprint hash changes (base.md was updated)
Shows dependency status

Where do blueprints live? The blueprint files need a central home that all projects can access. This is a team/company culture decision with two good options:

Option A: blueprints/ directory in the Lumina5 monorepo (simplest — the team already works here and all shared packages come from here)
Option B: A dedicated b4m-blueprints repo (cleanest separation — also provides a natural home for the future cross-product awareness system)

Implementation discovery

When /apply-blueprint runs, it can optionally discover existing implementations to use as examples:

Check locally accessible repos — if the developer has other product repos checked out, the skill can scan them for blueprint-manifest.json and offer their implementations as references
Generate from blueprint only — if no other repos are accessible (or the developer prefers), the skill generates entirely from the blueprint's architectural knowledge. Blueprints must always work without any reference implementation available.

Future: cross-product awareness

As the number of products and teams grows, we'll need tooling for cross-product visibility — knowing which projects use which blueprints, which fixes are pending where, and surfacing new amendments to the right teams. We don't know what form this takes yet. It could be as simple as a scheduled agent that scans manifests and posts to Slack, or as sophisticated as a dedicated service with dashboards, project registry, LLM-powered analysis, and automated alerting.

We'll design this when we have the real problem. The blueprint-manifest.json in each project is the foundation — any future cross-product system reads from these manifests. That's the only day-one requirement: keep your manifest accurate (which the skills handle automatically).

Evidence: why the quest loop must be a blueprint

From Stormy's Polaris codebase audit — the strongest evidence for blueprinting over packaging.

Lumina5's ChatCompletionProcess.ts and Polaris's questStart.ts solve the same problem (agentic LLM loop with tool calling) but have fundamentally different architectures:

Aspect	Lumina5	Polaris
Tool loading	Sequential	Parallel via `Promise.all(toolInitPromises)`
Tool chaining	Basic	`_isMcpTool` pattern preserves tools across turns
Streaming	Direct	Throttled (100ms), with rapid reply handoff
Stop handling	Per-message	Throttled polling (3s) to prevent DB storms
Context overflow	Fail	Auto-retry with condensed tool results
Progress updates	None	WebSocket batch progress, heartbeat every 15s
Citation extraction	Basic	Full source manifest from tool results
Subscription gating	None	Domain-aware tool access per subscription tier

Forcing these into one @b4m/quest package means either (a) Polaris fights the abstraction, or (b) the package grows 50+ configuration knobs. Neither works.

A quest blueprint with a shared interface (IQuestEngine, IReActLoop) lets each product implement what it needs. Concrete amendments from Polaris that other products could apply:

blueprints/quest/
  base.md                          # Core ReACT agentic loop pattern
  0001_isMcpTool.md                # From Polaris: preserve tools across multi-turn
  0002_rapid_reply.md              # From Polaris: parallel lightweight response
  0003_stream_heartbeat.md         # From Polaris: 15s status updates during silence
  0004_context_overflow_retry.md   # From Polaris: auto-retry with condensed results
  0005_subscription_gating.md      # From Polaris: domain-aware tool access per tier

IonQ might apply base + 0001_isMcpTool + 0003_stream_heartbeat but skip 0005_subscription_gating (they don't have subscription tiers). Each product picks the amendments that fit.

Evidence: why data lake service is a blueprint (not a package)

Stormy's initial analysis identified data-lake as a package candidate. The git history analysis refined this — the FAB pipeline portion is indeed a package, but the data lake service layer on top shows significant product-specific evolution:

Lumina5 data lake service: 1 commit in 6 months (a structural refactor — zero logic changes)
Polaris data lake service: 18 commits with heavy product customization:
- 11-phase Data Lake Wizard (full port)
- Folder-based taxonomy system
- Archive/unarchive lifecycle management
- Segment tags and content sampling
- OpenSearch cleanup automation

The FAB pipeline (chunking, vectorization, search indexing) is stable and shared — that's @b4m/fab-pipeline (a package). But the data lake service layer on top of it (how data lakes are created, organized, managed, presented to users) is product-specific business logic that diverges rapidly.

This distinction is important: the plumbing is a package, the business logic on top is a blueprint.

When do you create a blueprint?

This is Isao's question, and the answer evolves with team maturity:

Phase 1: Retroactive (where we start)

A blueprint is created when a second product needs the same capability. The team that first built it writes the base.md and interfaces.ts, retroactively — extracting the architectural knowledge from their implementation. This is low overhead — you only blueprint what's actually being reused.

Pattern: Product A builds a capability → Product B needs it → extract a blueprint from the knowledge → Product B generates their own implementation informed by the blueprint and Product A's example.

Phase 2: Proactive (where we grow)

As the team builds muscle memory, new features are built as blueprints from the start. The developer writes the interface and base.md alongside the implementation. This is a lightweight discipline — not a gate, just a habit.

Pattern: design interface → build implementation → write base.md → both ship together.

Phase 3: Blueprint-first (the aspiration)

In the ideal state, every significant feature is a blueprint or a blueprint amendment. New features in any product are designed as amendments that could be applied elsewhere. The blueprint library becomes the architectural knowledge base for the entire organization.

We don't need to be here on day one. Start retroactive. Graduate to proactive as the pattern proves itself.

How bug fixes propagate

By severity

Severity	Propagation	Mechanism
P0 (Security)	Package update + coordinated deploy	Fix is in `@b4m/auth` or `@b4m/core` (true packages). Code consistency is automatic via dependency. Deployment timing is operational — all products should deploy P0 package updates within a defined SLA (e.g., 24 hours). CI should flag outdated security-critical package versions.
P1 (Critical)	Fix advisory via `/amend-blueprint`	Team that found the issue runs `/amend-blueprint` which creates a `FIX_` advisory. Other teams run `/apply-blueprint` which auto-evaluates and applies, adapts, or skips with a documented reason.
P2-P3 (Important/Minor)	Amendment via `/amend-blueprint`	Fix or improvement lands as a new amendment. Product teams apply via `/apply-blueprint` when convenient, or discover it via `/blueprint-status`.

Fix advisories

A fix advisory is a special amendment marked as urgent. The critical difference from packages: each team evaluates whether the fix is relevant to their implementation before applying.

Real-world example: a critical bug was found in Polaris's data lake and fixed. When the fix was brought to Lumina5, it was discovered that the issue could never occur in Lumina5 because of different underlying infrastructure. The fix was irrelevant. With a package, this evaluation still has to happen (you have to test the version bump). With blueprints, the evaluation is explicit and the reasoning is documented.

How it works: Claude Code evaluates automatically

The developer doesn't manually evaluate whether a fix applies. They just run /apply-blueprint data-lake and Claude Code figures it out. It finds the pending fix, reads the advisory, studies the project's implementation, and determines one of four outcomes:

Fix applies → applied automatically. Claude Code finds the same vulnerability in your code, generates the fix adapted to your implementation, and records it in the manifest.
Fix partially applies → adapted automatically. The root cause is similar but your architecture is different. Claude Code generates an adapted version of the fix and explains what it changed and why.
Fix doesn't apply → skipped with reason (after developer confirms). Claude Code analyzes your implementation and determines the issue can't happen here — different infrastructure, different patterns, or the vulnerability doesn't exist. It explains the reasoning to the developer. The developer either agrees (skip is recorded in manifest with the reason) or pushes back and they discuss until reaching a final assessment.
Fix reveals a deeper issue → flagged for blueprint update. Claude Code discovers that the bug points to a design flaw that the blueprint should warn about. It suggests an update to the blueprint's ARCHITECTURE.md.

Real-world example: a critical fix PR from Polaris was handed to Lumina5. Claude Code was asked to apply it and determined on its own that the fix was not needed — Lumina5's different underlying infrastructure made the vulnerability impossible. Claude Code explained why, and the fix was skipped. The reasoning was documented.

Recording in manifest

The blueprint-manifest.json records the outcome automatically — applied, adapted, or skipped with reason. The skip reason documents why the issue can't happen here — valuable knowledge for future team members and auditors.

Isao's key insight: this is a social/culture contract first, not a technical system with guardrails.

What we agree to (day one)

Blueprints are the shared knowledge, implementations are examples. When building something new, check if a blueprint exists and search for existing implementations across projects. Design from customer requirements down — the blueprint and other projects' implementations are accelerators, not constraints. No single project is “the reference.”
When porting, write a blueprint. If you're moving a capability from one repo to another, take 30 minutes to write a base.md and interfaces.ts. Future ports will be faster.
Interfaces are the real contract. Shared TypeScript interfaces in blueprints/*/interfaces.ts define what “compatible” means. Products should satisfy these interfaces even if their implementation is completely different. When /amend-blueprint updates interfaces.ts, it automatically classifies the change as non-breaking (new optional fields/methods — safe) or breaking (removed/changed required fields — requires migration).
Own your code. Generated code is your code. You maintain it, you debug it, you evolve it. Test generated code before shipping — blueprints may include test patterns, but products own their test suite.
Contribute back. When you fix a bug or add a useful feature, consider writing an amendment for the blueprint so other products benefit.
Security is non-negotiable. @b4m/auth and @b4m/core are true packages. No product rolls their own auth. Enforced by CI: a lint check flags any product directly importing passport, jsonwebtoken, or bcrypt instead of through @b4m/auth.
Blueprints must document authorization patterns. Every blueprint base.md must include an “Authorization Patterns” section specifying what permission checks the generated implementation must include. Authorization is business logic that lives in generated code — it must be explicitly designed, not silently omitted.
Rollback is via git. /apply-blueprint generates all files as unstaged changes — nothing is committed automatically. The developer reviews everything, then makes a single commit. If something goes wrong, discard the unstaged changes or revert the commit.

Authorization security in generated code

Auth (who you are) is a package. Authorization (what you can do) is business logic in generated code. This is the highest-risk area of the blueprint architecture.

Mitigations:

Blueprint authorization section (required): every base.md includes an “Authorization Patterns” section documenting required permission checks. /apply-blueprint reads this section and includes authorization in generated code.
Security review checklist for generated code:
- Every query filters by org/user permissions
- No raw database queries bypass the authorization layer
- Error messages don't leak unauthorized data
- Pagination doesn't allow enumeration of unauthorized resources
- File upload/download checks data lake membership
- CASL ability checks are present at every data access point
CASL policy validation: @b4m/auth should include a utility that validates CASL policy definitions against a schema at startup, preventing products from silently adding overly permissive rules.
Tenant data isolation: for enterprise customers like IonQ, @b4m/db-core should provide Mongoose plugins or middleware that automatically scope queries by organization, preventing cross-tenant data leakage at the database layer. This is infrastructure-level isolation that belongs in a true package, not in generated code.
Generated code secrets handling: /apply-blueprint generates code that references secrets via @b4m/infra secret manifest patterns — never hardcoded values. The manifest declares what secrets are needed; the product's infrastructure provisions them.

What we don't need yet (evolve later)

Formal conformance test suites (TCK) — start with shared interfaces and manual review
Contract versioning governance — use the migration/amendment pattern naturally
Automated breaking change detection — TypeScript compiler catches most interface breaks
Formal blueprint review process — just PR review like any other code
Mandatory conformance testing in CI — add when we have enough products to justify the investment

The guardrails emerge from experience. If we find that products are drifting in dangerous ways, we add a conformance test. If we find that contract changes are breaking things, we add governance. But we don't build the bureaucracy before we know what problems we actually have.

Drift detection: during quarterly architecture review, compare product implementations against blueprint interfaces. If >2 products have incompatible implementations of the same interface, consider adding conformance tests for that capability.

Product assembly (what IonQ AGI looks like)

True Packages (imported — stable infrastructure):
  @b4m/core           — types, schemas, error envelope
  @b4m/auth           — enterprise auth, API keys, rate limiting, CASL engine, trial middleware
  @b4m/infra          — SST factories, secret manifests
  @b4m/observability  — structured logging, correlation IDs
  @b4m/db-core        — BaseRepository, connection management
  @b4m/fab-pipeline   — SmartChunker, EmbeddingFactory, BaseSearchIndex (the frozen core)
  @b4m/llm-adapters   — ICompletionBackend, getLlmByModel() (raw provider interfaces)
  @b4m/blueprints     — /create-blueprint, /amend-blueprint, /apply-blueprint, /blueprint-status skills

Generated from Blueprints (owned by IonQ team):
  data-lake/base + custom_quantum_parsing
  llm-orchestration/base + custom_anthropic_primary
  quest/base + custom_briefcase_for_sales
  enterprise-config/base + 0001_soc2_audit_trail
  realtime/base
  tools/base (IonQ-specific tools registered at product level)

Package for now, blueprint if needed later:
  @b4m/mementos       — memory tiers (only Lumina5 has it today)
  @b4m/artifacts      — artifact rendering (dormant, no divergence yet)

Product-Specific (always unique):
  pack-quantum        — quantum solvers, IonQ API, paper reproduction
  pack-sales          — customer KB, proposal engine, quantum advantage scoring

What IonQ AGI does NOT get: Polaris UI, SIGNAL, Market Coverage, BEV, Always Live Market Model, CYA/cyber tools, Tavern, Slack integration.

Extraction roadmap

Two parallel tracks

Per Isao's guidance: don't tie architecture refactoring to IonQ. Let IonQ move at maximum speed. Blueprint system matures in parallel.

Track A: IonQ AGI (customer-driven, maximum speed). Build from requirements down. Don't wait for the blueprint system to be perfect.
Track B: Blueprint platform (architecture-driven, parallel). Build the shared tooling, packages, and blueprints. IonQ adopts them when ready.

Team allocation: these tracks can share engineers, but each track needs a clear lead. Track A is driven by IonQ customer requirements; Track B is driven by the architecture quorum. When an engineer is building for IonQ (Track A) and recognizes a generalizable pattern, they flag it for Track B extraction — but they don't block IonQ delivery to do so.

Convergence checkpoint: at the IonQ A1 gate (minimum deliverable), evaluate whether any Track B blueprints are available and suitable for adoption. If Track B has delivered usable blueprints, IonQ begins adopting them. If not, IonQ continues independently and Track B catches up.

If blueprints aren't ready when IonQ needs a capability, IonQ builds it directly (from the B4M shell or from scratch) — they don't wait.

Track A: IonQ AGI

A0: Start from B4M Shell (P0 — start immediately) — Isao's “maximally reduced B4M shell” approach.

Fork Lumina5 into IonQ's product directory
Strip everything that is “functionality” — remove Tavern, Slack, CYA, SRE, Polaris-specific code, game engine, whatsNew, etc.
Keep only the essentials: Storage, Auth, Admin, basic Next.js/SST scaffold, MongoDB connection
Optimization/cleanliness pass — this becomes B4M Base, a clean starting point
Begin IonQ requirements gathering in parallel (SOW details, auth integration, user profiles, data access controls)

B4M Base as a reusable template: once validated, B4M Base should be maintained as the starting template for future products (LibreOncology, Starlight, etc.) — not a one-off fork. Each new product starts from the latest B4M Base, not from Lumina5 directly.

Gate: clean, running B4M Base with auth + storage + admin. IonQ team can start building on top.

A1: IonQ minimum deliverable (P0)

Build IonQ's data lake (from B4M Base, or from blueprint if available)
Build IonQ's briefcase experience (quest loop + LLM + tools)
Build IonQ-specific sales tools (pack-sales)
Configure enterprise controls (RBAC, SOC2 audit trail)
Deploy to IonQ's AWS account

Convergence checkpoint: at this gate, evaluate Track B blueprints for adoption.

Gate: IonQ field sales team can use the Briefcase over a quantum data lake.

A2: IonQ enrichment (P1)

Add mementos/memory if IonQ needs it
Add artifact rendering if IonQ needs it
Integrate quantum-specific tools (pack-quantum)
API access for IonQ's external agents

Gate: full IonQ Bucket 1 delivered.

Track B: Blueprint platform

B0: Core packages + tooling (P0 — start in parallel with A0)

Add Turborepo — build orchestration for the monorepo
Extract true packages: @b4m/core, @b4m/auth, @b4m/infra, @b4m/observability, @b4m/db-core, @b4m/fab-pipeline, @b4m/llm-adapters
Build @b4m/blueprints — a key deliverable in B0, built in parallel with package extraction. Claude Code skills: /create-blueprint, /amend-blueprint, /apply-blueprint, /blueprint-status.
Reorganize packages/database into domain sub-packages

Gate: packages build independently. @b4m/blueprints skills working.

B1: First blueprints + spike (P0)

Use /create-blueprint to write the first 3 blueprints (studying existing implementations across Lumina5 and Polaris):
- blueprints/data-lake/ — base + interfaces + authorization patterns + ARCHITECTURE.md
- blueprints/llm-orchestration/ — base + interfaces + ARCHITECTURE.md
- blueprints/enterprise-config/ — base + interfaces + ARCHITECTURE.md
Spike: generate a test implementation from one blueprint. Validate the workflow end-to-end.

Gate: first 3 blueprints created. Spike validates the generation workflow.

B2: Quest + tools blueprints (P0–P1)

/create-blueprint quest and /create-blueprint tools
Write blueprints for: realtime (and others as needed — media, email, etc. are created when a second product needs them)

Gate: full blueprint library for all major capabilities.

B3: IonQ adoption (when ready)

IonQ team evaluates available blueprints against what they've already built
Adoption means: IonQ validates their existing implementations satisfy blueprint interfaces. Where they diverge, the team decides case-by-case whether to refactor toward the blueprint or contribute their approach back as an alternative amendment.
IonQ contributes back: any patterns they built that are generalizable become shared amendments.
If IonQ built first: IonQ's implementation becomes another example that future products can study.

Gate: IonQ has adopted relevant blueprints and contributed amendments back.

Track C: Polaris (P1 — after latency P1 resolved)

Stormy's recommended migration sequence — prioritizes latency impact:

@b4m/llm-adapters package adoption — replace Polaris's getLlmByModel() with shared adapters. Directly helps latency (Erik's #1 priority). Lowest-risk swap.
Quest blueprint adoption — Polaris keeps questStart.ts but satisfies the quest interface contract. Contributes _isMcpTool, rapid reply, stream heartbeat back as shared amendments.
Data lake blueprint — Polaris already has 18 product-specific commits. Satisfy the interface contract; keep Polaris's wizard/taxonomy/archive features as local customizations.
@b4m/fab-pipeline package adoption — replace Polaris's internal chunker/vectorizer with the shared package. Already consuming SmartChunker from @bike4mind/utils, so this is a rename.
Enterprise config blueprint — Polaris keeps its 50+ features, 8 roles, 60+ event types. Satisfies the enterprise interface contract.
DB reorganization — defer until packages are proven. 159 models is the highest-risk migration.
Write blueprints/cyber/ from CYA engine.

Important: extraction effort ≠ consumption effort. Stormy's audit identified that Polaris needs significant decoupling work to consume shared packages:

Data pipeline is ~60% coupled to Next.js (queue handlers send WebSocket updates directly with hardcoded action types)
251+ aggregation calls scattered across 115 files need consolidation into repository methods
62 of 72 repositories lack explicit domain interfaces
API routes contain business logic that needs extraction to service layer

Each of these is medium effort and should be scoped separately from the blueprint/package extraction work.

Gate: Polaris consumes @b4m/llm-adapters + @b4m/fab-pipeline packages and satisfies blueprint interfaces for quest, data-lake, enterprise.

Track D: DB abstraction + guardrails (P2)

If experience shows products are drifting dangerously, add conformance tests (TCK)
If contract changes are causing breakage, add formal governance
Define IDataStore interface in blueprints, implement MongooseDataStore
Optional: PostgresDataStore for products that need it

Gate: guardrails match actual problems, not hypothetical ones.

Comparison: packages vs blueprints vs hybrid

Dimension	Pure Packages	Pure Blueprints	Hybrid (recommended)
Shared code	~17 npm packages (Package Architecture Proposal)	~8 core packages + blueprints	~8 core packages + blueprints
Capability reuse	Import as dependency	Generate from blueprint	Packages for stable infra, blueprints for business logic
Customization	Configuration/extension	Full source ownership	Full ownership where it matters
Bug fixes	Auto via version bump	Severity-based (auto for P0, advisory for P1+)	Same as blueprints
Coupling	Runtime dependency	Generation-time influence	Minimal runtime coupling
Overhead	Low ongoing	Medium (blueprint maintenance)	Medium
Team autonomy	Constrained by package API	Full within interface boundaries	High
Day-one complexity	Moderate (extract 17 packages)	Low (extract 8 core packages + write 3 blueprints)	Low
When products diverge	Fight the abstraction	Natural — that's the design	Natural

Recommendation: start with the hybrid. True packages for the stable core. Blueprints for everything else. Add guardrails (TCK, governance) only when experience shows they're needed.

Industry precedents

This proposal is a synthesis of proven patterns, accelerated by AI:

Pattern	Industry Example	How We Use It
Software Templates	Spotify Backstage — generates projects from templates, catalog tracks all instances	`/create-blueprint` generates blueprints, manifests track all implementations
Architecture Decision Records	Widely adopted (GitHub, Thoughtworks) — document why decisions were made	`ARCHITECTURE.md` and amendments capture decisions and trade-offs
Inner Source	PayPal, Microsoft, SAP — cross-team code contribution with social contracts	“Contribute back” social contract, `/amend-blueprint` for sharing improvements
Contract-First Development	Google Protocol Buffers, gRPC — shared interfaces with independent implementations	`interfaces.ts` defines the contract, implementations are independent
Code Generation from Patterns	Rails generators, Nx schematics, Yeoman — scaffold code from architectural knowledge	`/apply-blueprint` generates adapted implementations from blueprints

The AI innovation: traditional generators use rigid templates with variable substitution. Claude Code generates contextually adapted implementations that understand the target project's conventions, existing code, and specific requirements. This collapses the cost of “adapt and customize” from expensive manual work to a conversation.

Risk assessment

Risk	Likelihood	Impact	Mitigation
Products drift in incompatible directions	Medium	Medium	Shared interfaces catch structural drift at compile time. Add conformance tests later if needed.
Blueprint quality varies	Medium	Medium	The blueprint itself is the source of truth, not any single project. Review blueprints like code — PR review for all changes to `blueprints/`.
Team doesn't write blueprints	Medium	Medium	Start retroactive (only when reuse happens). Low barrier.
AI generation produces subtle bugs	Medium	High	Human review + interface type checking + product team owns the code and tests it. Security-sensitive paths (authorization, data access, billing) should require review from a second engineer.
Security gaps in generated code	Medium	High	Auth is a true package. Authorization patterns documented in ARCHITECTURE.md. Security review on generated code.
AI unavailable or quality degrades	Medium	Medium	Blueprints work without AI — they're architectural knowledge + interfaces that a developer can follow manually, studying existing implementations across repos as examples. AI is an accelerator, not a load-bearing wall. However, model regressions can produce subtly incorrect generated code that passes type checks but has behavioral bugs. Mitigated by mandatory human review of all generated code.

Resolved questions

#	Question	Decision	Notes
1	Migration/amendment model or simpler?	Let the tooling decide. Whatever structure `@b4m/blueprints` skills need to work well is the right structure.	Don't over-prescribe the format before the skills exist.
2	How lightweight should day-one blueprints be?	Whatever `/create-blueprint` generates. If Claude Code needs more context to generate well, the skill will create it.	The skill defines the standard, not a document.
3	Spike before committing?	Yes — spike first. Build `@b4m/blueprints` skills, test on data-lake, validate the workflow.	This is the hard gate. If the spike fails, fall back to packages.
4	When to add conformance tests (TCK)?	After a drift-related bug. Don't build the bureaucracy until we have evidence of the problem.	TypeScript interfaces + code review are the day-one guardrails.
5	Blueprint ownership?	Shared/unowned. Anyone can amend. PRs reviewed like any other code.	See “Open Question” below — amendment sharing across products needs more design.
6	Every feature as a blueprint?	Aspire but don't mandate. Make it easy with tooling. Encourage culturally. Don't gate PRs on it.	`/create-blueprint` makes the overhead minimal. Culture does the rest.
7	Build tooling first or manual first?	Tooling first. Build the skills, then use them to create the first blueprints. Validates the tooling immediately.	`@b4m/blueprints` is a key deliverable in B0, built in parallel with package extraction.
8	Cross-product registry?	When fix advisories need targeting. Build the registry when we need to know “which products are affected by this fix?”	That's the first real use case for cross-product awareness.

Open questions for the quorum

Most questions are resolved. These remain for discussion:

Blueprints are shared/unowned, but there's an unsolved workflow: how do amendments discovered in one product get shared back to the blueprint library?

Example: IonQ's team discovers a better chunking strategy while working on their data-lake. They write a local amendment (custom_better_chunking.md). How does this become a shared amendment (0004_better_chunking.md) that Polaris and LibreOncology can also apply?

Possible approaches:

PR to blueprints directory — IonQ team submits a PR promoting their local amendment to a shared amendment. Reviewed like any other code.
/promote-amendment skill — a future skill that takes a local amendment and converts it to a shared one, handling the renumbering and dependency declarations.
Amendment review process — shared amendments need at least one review from a team that didn't write it, to ensure it's generalizable.

2. What does the spike success/failure look like?

The spike (step B1-2) is the hard gate. What criteria make it a success vs failure?

Proposed success criteria:

/create-blueprint data-lake produces a usable blueprint from Lumina5's code
/apply-blueprint data-lake generates a working implementation for a test product
Generated code satisfies the shared TypeScript interfaces
Total effort (tooling + blueprint + generation + manual fixes) is less than the effort of extracting a traditional package
The team feels the workflow is natural, not burdensome

If the spike fails, the fallback is the Package Architecture Proposal (which shares the same Layer 1 foundation).

3. Routing divergence between Lumina5 and Polaris

Flagged by Stormy's audit.

Lumina5 uses Tanstack Router (SPA, client-side routing). Polaris uses Next.js Pages Router (SSR, 100+ API routes in pages/api/). These are fundamentally different routing architectures.

Resolved — hard design constraint for B0: routing is product-specific. Blueprints and packages MUST be router-agnostic. @b4m/auth MUST expose router-agnostic middleware (framework adapter pattern) as a B0 acceptance criterion. This is non-negotiable — auth is the most security-critical package and both Polaris and IonQ must be able to consume it regardless of their routing choice.

4. IonQ delivery questions (from Isao)

These need answers before Track A0 begins:

What does the SOW actually say? What are the contractual deliverables?
Should IonQ hook into their internal auth system? Or standalone B4M auth?
Who is the initial user? How many of them?
How do they want to design access controls around their data?
What level of access do we have to their data?
IonQ will want source code access — what are the implications for code cleanliness and documentation?

5. Is this a reset? (from Isao)

IonQ is a greenfield deployment. Should we reconsider fundamental choices?

MongoDB — is it the right database for IonQ, or should we evaluate alternatives?
SST vs Pulumi/Terraform — SST is the team's standard, but is there a reason to consider alternatives for IonQ?
Packages vs services — should some capabilities be deployed as independent microservices rather than in-process packages?

Current proposal assumes: MongoDB + SST continue. But these questions are worth 30 minutes of quorum discussion.

Contributions & evolution

This proposal was shaped by the entire quorum. Each person's feedback fundamentally improved the architecture:

Contributor	Contributions
Ken Wallace	Original blueprint concept. Key insight: blueprints are architectural knowledge above any single codebase — not tied to Lumina5 or any project. Manifest-based discovery across repos lets `/apply-blueprint` find the closest existing implementation as an example.
Isao Jonas	Social contract first, not technical guardrails. Migration/amendment model for versioning. Strategic principle: “Your strength is in implementation and agility, not existing code.” Parallel tracks (don't tie architecture to IonQ). B4M Shell as fast-start alternative.
Stormy Emery	Polaris codebase audit with hard numbers (159 models, 124 quest commits, 112 domain tools). Quest loop divergence evidence proving blueprints over packages. Enterprise engine/config split. Polaris migration sequence prioritizing latency.
Victor	Raised critical fix propagation concerns that drove the auto-evaluation system. Fix advisories that Claude Code automatically evaluates, applies, adapts, or skips — with documented reasoning. One-command workflow where developers don't need to know amendment names. Blueprint hash tracking for detecting when blueprints themselves have been updated.
Git history validation	Data-driven package vs blueprint split. 6 months of commit data from both repos proved which capabilities are truly frozen infrastructure (package) vs actively evolving business logic (blueprint).

Relationship to other proposals

Proposal	Status	Relationship
PR #7673 (Strawman)	24 packages / 5 layers	Blueprint v2 is a fundamentally different approach — knowledge sharing vs code sharing
Package Architecture Proposal	17 packages / 3 tiers	Shares the same Layer 1 (true packages). Differs on Layer 2 — packages vs blueprints.
Blueprint v1	Over-specified mechanics	v2 pares back to social contract. Migration model replaces semver. Guardrails are earned, not imposed.

The quorum can choose packages, blueprints, or hybrid. All three share the same Layer 1 foundation and the same IonQ acid test.

Key insight from the git history validation

Stormy recommended 12–15 packages. The git data says 8 core packages + 2 provisional + blueprints for the rest. The difference is that several capabilities Stormy called “infrastructure” (data-lake service, LLM orchestration, realtime) are actually actively evolving product-specific code in Polaris with 10–124 commits of customization. Only package what's truly frozen. Blueprint everything that's actively evolving.

The idea in one paragraph​

Why not just packages?​

The architecture​

Strategic principle​

Two layers, validated by git history​

Layer 1: True packages (stable, shared — rarely change)​

Layer 2: Blueprints (actively evolving, product-specific)​

The decision rule​

The hard numbers​

Blueprints as migrations​

Blueprint dependencies​

@b4m/blueprints — the blueprint lifecycle package​

Why a package?​

The manifest (blueprint-manifest.json)​

Claude Code skills​

/create-blueprint — extract a blueprint from existing code​

/amend-blueprint — share a fix, feature, or improvement back to the blueprint​

/apply-blueprint — the single entry point for consuming blueprints​

/blueprint-status — check your product's blueprint state​

Implementation discovery​

Future: cross-product awareness​

Evidence: why the quest loop must be a blueprint​

Evidence: why data lake service is a blueprint (not a package)​

When do you create a blueprint?​

Phase 1: Retroactive (where we start)​

Phase 2: Proactive (where we grow)​

Phase 3: Blueprint-first (the aspiration)​

How bug fixes propagate​

By severity​

Fix advisories​

How it works: Claude Code evaluates automatically​

Recording in manifest​

The social contract​

What we agree to (day one)​

Authorization security in generated code​

What we don't need yet (evolve later)​

Product assembly (what IonQ AGI looks like)​

Extraction roadmap​

Two parallel tracks​

Track A: IonQ AGI​

Track B: Blueprint platform​

Track C: Polaris (P1 — after latency P1 resolved)​

Track D: DB abstraction + guardrails (P2)​

Comparison: packages vs blueprints vs hybrid​

Industry precedents​

Risk assessment​

Resolved questions​

Open questions for the quorum​

1. Amendment sharing across products​

2. What does the spike success/failure look like?​

3. Routing divergence between Lumina5 and Polaris​

4. IonQ delivery questions (from Isao)​

5. Is this a reset? (from Isao)​

Contributions & evolution​

Relationship to other proposals​

Key insight from the git history validation​

The idea in one paragraph

Why not just packages?

The architecture

Strategic principle

Two layers, validated by git history

Layer 1: True packages (stable, shared — rarely change)

Layer 2: Blueprints (actively evolving, product-specific)

The decision rule

The hard numbers

Blueprints as migrations

Blueprint dependencies

`@b4m/blueprints` — the blueprint lifecycle package

Why a package?

The manifest (`blueprint-manifest.json`)

Claude Code skills

`/create-blueprint` — extract a blueprint from existing code

`/amend-blueprint` — share a fix, feature, or improvement back to the blueprint

`/apply-blueprint` — the single entry point for consuming blueprints

`/blueprint-status` — check your product's blueprint state

Implementation discovery

Future: cross-product awareness

Evidence: why the quest loop must be a blueprint

Evidence: why data lake service is a blueprint (not a package)

When do you create a blueprint?

Phase 1: Retroactive (where we start)

Phase 2: Proactive (where we grow)

Phase 3: Blueprint-first (the aspiration)

How bug fixes propagate

By severity

Fix advisories

How it works: Claude Code evaluates automatically

Recording in manifest

The social contract

What we agree to (day one)

Authorization security in generated code

What we don't need yet (evolve later)

Product assembly (what IonQ AGI looks like)

Extraction roadmap

Two parallel tracks

Track A: IonQ AGI

Track B: Blueprint platform

Track C: Polaris (P1 — after latency P1 resolved)

Track D: DB abstraction + guardrails (P2)

Comparison: packages vs blueprints vs hybrid

Industry precedents

Risk assessment

Resolved questions

Open questions for the quorum

1. Amendment sharing across products

2. What does the spike success/failure look like?

3. Routing divergence between Lumina5 and Polaris

4. IonQ delivery questions (from Isao)

5. Is this a reset? (from Isao)

Contributions & evolution

Relationship to other proposals

Key insight from the git history validation