# Advisory Council Simulation Event — Vision 2026 Full Review

**Date:** 2026-03-10
**Session Type:** SIMULATION (Full Design Review)
**Arbiter:** AI Advisory Council System v1.0.0
**Council:** 12 advisors (full council)
**Topic:** LLMHosts Vision 2026 Masterplan — Pre-implementation Red Team
**GitHub Issue:** #480

---

## Session Protocol

1. Each advisor independently assessed the Vision 2026 masterplan before this session
2. Six topics were debated: Smart Install (#472), Collective Intelligence (#475), Fine-Tuning (#477), IP Protection (#479), Install Time Claims, and Competitive Moat
3. Red team mandate: At minimum 3 advisors argue against emerging consensus on each topic
4. Mandatory dissent designees: Raghunathan, Okonkwo, Bergström (for positive items); Tanaka, Nwosu, Al-Rashid (for negative items)
5. Votes: GO / GO WITH CONDITIONS / NO-GO with specific conditions

---

## Topic 1: Wave 1 Smart Install — Universal GPU Detection Feasibility (#472)

### Arbiter Framing

Wave 1 proposes pre-install platform detection via a hatchling build hook that selects the correct wheel variant before installation completes. The platform matrix covers NVIDIA+CUDA, AMD+ROCm, Apple+Metal, Intel+Vulkan, and CPU. Success metric: "doctor pass rate > 92% across all four GPU families on first run."

### Position Statements

**Yuki Tanaka (DX):** "The concept is sound and necessary. Users should not have to configure compute backends. The hatchling hook approach is the right architecture. My concern is not the design but the failure handling — specifically, what the user sees when detection returns an ambiguous result or when the wrong wheel is selected."

**Dr. Kwame Boateng (Hardware):** "The detection is feasible for NVIDIA and Apple Silicon — NVML and IOKit are reliable. AMD ROCm detection via sysfs is unreliable on older kernels. Intel Arc Level Zero detection requires the L0 loader to be installed, which most users haven't done. The '92% pass rate' metric is achievable only if Intel Arc is excluded or treated as experimental."

**Dr. Priya Raghunathan (Performance):** "The GPU detection is fine. My concern is what happens after detection. The 'correct binary' for NVIDIA requires CUDA to be installed and at the right version. The hatchling hook can detect that the user has an NVIDIA GPU, but it cannot verify that CUDA 11.8+ is installed. If CUDA isn't installed, the NVIDIA wheel silently degrades to CPU mode. This is a poor user experience."

**Dr. Hans Bergström (Feasibility):** "The engineering scope of four separate GPU detection paths, four separate wheel variants, and platform-specific binary distribution via PyPI is 8-12 weeks of work. The masterplan assigns this to Wave 2 (Weeks 6-12 from today) but it depends on Wave 1 GPU compute being complete. The dependency chain is tighter than stated."

**Marcus Okonkwo (Security):** "The hatchling hook runs arbitrary Python code at pip install time. This is a significant supply chain attack surface — malicious hook injection could execute code on every user's machine. The hook code must be: minimal, auditable, and pinned to a specific version. The hook should only read hardware info, never write files or make network calls."

**Dr. Santiago Vega (Distributed):** "The detection hook runs once at install time. But GPU configurations can change — a user might add a second GPU, upgrade drivers, or install ROCm after the initial install. Is there a `llmhosts reconfigure` path that re-runs platform detection and selects the correct backend without reinstalling?"

**Amara Nwosu (Business):** "The 90-second install claim is cited for marketing. A hatchling hook that does GPU detection, downloads the right binary variant, and verifies it adds 10-30 seconds to install time. That's acceptable. But the install of a maturin-compiled Rust wheel for NVIDIA includes compiling CUDA PTX shaders on first run — that's 30-60 seconds on top. The 90-second claim needs to be more specific."

**Fatima Al-Rashid (Competitive):** "Ollama's install is `curl -fsSL https://ollama.com/install.sh | sh` and it works. llama.cpp's install is `brew install llama.cpp`. Neither requires pip. Our pip-based install immediately creates friction with a non-trivial developer audience that avoids Python dependency management. Should there be a Homebrew formula and a standalone binary installer in addition to pip?"

### Cross-Examination

**Raghunathan → Boateng:** "You said AMD sysfs detection is unreliable on older kernels. Specifically, which kernel versions? What percentage of AMD users on Linux run kernels where this fails?"

**Boateng → Raghunathan:** "Linux kernel < 5.4 (EOL, but still deployed in enterprise) doesn't expose the amdgpu sysfs path reliably. That's maybe 10-15% of Linux AMD users. More critically, the RX 7900 XTX requires kernel 6.2+ for stable ROCm 6.x — and many distros ship 5.15 LTS. So the '92% pass rate' is achievable on NVIDIA but may be 70-75% on AMD."

**Okonkwo → all:** "Has anyone done a threat model for the hatchling hook? A compromised crates.io or PyPI dependency that reaches the hook execution context can exfiltrate GPU model and VRAM to a third party. The hook must be isolated and its network access must be zero."

**Tanaka → Vega:** "The reconfigure path you mentioned — this is actually a critical journey moment. When a user upgrades their GPU and reinstalls, they should see 'We detected your new RTX 5090! Reconfiguring...' That's a delight moment for the upgrade path. Can we build that as an explicit `llmhosts upgrade-hardware` command?"

### Red Team Arguments (MANDATORY)

**Red Team Lead:** Dr. Hans Bergström

**Bergström (RED TEAM):** "I argue against proceeding with Wave 1 Smart Install as specified. The 4-platform detection + 4-wheel matrix is premature for a solo engineer. The risk is that we ship a complicated install with 60-70% pass rate on AMD/Intel rather than a simple install that works 99% of the time on NVIDIA. The right approach for v1.0 is NVIDIA-only pre-install detection, CPU fallback, and stub the AMD/Apple/Intel paths with clear 'coming soon' messaging. This gets us to market faster with a reliable experience."

**Raghunathan (RED TEAM):** "The hatchling hook is architecturally risky. pip install runs as the user, but some CUDA operations require root (driver access). A hook that fails silently because it can't access NVML due to permissions creates a maddening experience. I'd rather the hook never run GPU detection and instead have `llmhosts doctor --init` as the first command in the setup flow."

**Okonkwo (RED TEAM):** "The supply chain risk of arbitrary code in a pip install hook is non-trivial. I recommend against it until we have an explicit security model for the hook. The attack surface it creates is disproportionate to the UX benefit of saving two commands."

### Vote

| Advisor | Vote | Condition |
|---------|------|-----------|
| Raghunathan | GO WITH CONDITIONS | NVIDIA-only in Wave 2; AMD/Intel/Apple as opt-in experimental; hook security model required |
| Boateng | GO WITH CONDITIONS | AMD/Intel marked experimental; 92% target revised to "NVIDIA + Apple 92%, AMD 75%, Intel N/A" |
| Tanaka | GO | Loves the concept; conditions on failure message quality |
| Bergström | NO-GO | Scope too large for Wave 2 timeline; recommend NVIDIA-only first |
| Okonkwo | GO WITH CONDITIONS | Hook security model must be designed and reviewed before shipping |
| Vega | GO WITH CONDITIONS | Reconfigure path must be designed; detection must be idempotent |
| Nwosu | GO | Market value of "works on everything" justifies the risk |
| Al-Rashid | GO WITH CONDITIONS | Add Homebrew and standalone installer in parallel to pip |
| Obi | GO | No privacy concerns with hardware detection |
| Kim | GO | |
| Marchetti | GO WITH CONDITIONS | Ensure hook code is clearly disclosed to comply with GDPR transparency (data collected = GPU info) |
| Ibrahim | GO WITH CONDITIONS | Failure path design is required before launch |

**Vote result:** 8 GO or GO WITH CONDITIONS, 1 NO-GO | **Threshold for feature addition: 8/12 → PASSES**

**Arbiter Synthesis:** Wave 1 Smart Install passes with conditions. The primary conditions are: (1) NVIDIA + Apple are first-class in Wave 2; AMD and Intel are experimental with explicit UX labeling; (2) the hatchling hook receives a security review before shipping; (3) the 92% pass rate metric is revised to be platform-specific; (4) alternative install paths (Homebrew, standalone binary) are on the Wave 2 roadmap.

**PQS Impact:** Smart Install as designed scores 55/100 on DX category currently (no detection). With the conditions met: estimated 75/100.

---

## Topic 2: Wave 4 Collective Intelligence & Federated LoRA (#475)

### Arbiter Framing

Wave 4 proposes a privacy-preserving collective intelligence system collecting 5 signal types from opted-in nodes, with differential privacy (ε ≤ 0.5), k-anonymity (k ≥ 100/500 depending on which document section is read), and federated gradient aggregation for the router model. This is the primary long-term moat.

### Position Statements

**Dr. Adaeze Obi (Privacy):** "The architecture is directionally correct. DP, k-anonymity, hashing embeddings before transmission — these are the right building blocks. The critical gaps are: (1) no sensitivity analysis to justify ε=0.5; (2) k=100 is too small for hardware profile cohorts; (3) gradient updates from federated LoRA fine-tuning are not claimed to be privately aggregated, only 'gradient updates not data.' Gradient updates can reconstruct data."

**Marcus Okonkwo (Security):** "The SHA-256(embedding) approach has a rainbow table vulnerability I outlined in my profile. More critically: who operates the aggregator server? The 'aggregator' receives signals from 5,000+ nodes. This server is a high-value target. If the aggregator is compromised, does an attacker get a statistical reconstruction of millions of routing decisions? What's the aggregator's security posture?"

**Dr. Santiago Vega (Distributed):** "The 'batch flush ≥ 1000 signals or 60s interval' design creates a significant engineering complexity. Nodes that go offline mid-batch lose their queued signals. The aggregator must handle idempotent signal ingestion (duplicate signals from retry). Has the signal batching protocol been designed with idempotency keys?"

**Dr. Priya Raghunathan (Performance):** "The embedding hash approach: `sha256(384-dim float32 embedding)` is 384 × 4 = 1,536 bytes hashed to 32 bytes. This is not semantically meaningful compression — it's fingerprinting. The signal `prompt_embedding_hash` provides exactly zero information to the aggregator about the prompt content, but it also provides zero value for training the router model, because the hash doesn't preserve semantic similarity. You can't train the Qwen router on `{sha256(embedding), chosen_backend}` — the model cannot learn from hashes. This design needs rethinking."

**Fatima Al-Rashid (Competitive):** "The 'compounding moat' argument requires 1,000+ opt-in nodes to be meaningful. At launch, you have zero. At 100 nodes, the HIM has less statistical confidence than a 2-hour benchmarking session. The collective intelligence is not a moat for the first 12 months — it's a feature that becomes a moat at scale. The marketing must be honest about this timeline."

**Amara Nwosu (Business):** "The opt-in rate target is > 60%. For a privacy-focused product marketed to developers who are skeptical of telemetry, 60% opt-in is achievable ONLY if the value exchange is crystal clear. 'Help us improve model recommendations for everyone' is weak. 'Your GPU's performance data, anonymously shared, gives you better model recommendations customized to your exact hardware' is strong. The value exchange needs to be explicit and immediate."

**Dr. Hans Bergström (Feasibility):** "The collective intelligence infrastructure is: a client-side signal collector, a batch queue, an aggregator server, a privacy pipeline (DP noise, k-anonymity), a HIM database, an API, and a federated learning coordinator. This is a separate SaaS product, not a Wave 4 feature. Realistically, this is 3-6 months of infrastructure work, not 8 weeks."

**Elena Marchetti (Legal):** "The GDPR analysis in Section 5.4 states 'right to deletion is impossible because we have no linkage.' This is not a GDPR-compliant approach. The fact that deletion is technically difficult does not remove the legal obligation. If any element of the collected data constitutes personal data under GDPR (and 'routing decisions' from an identifiable home user could), the DPA may not accept 'we use rotating HMACs' as sufficient."

### Cross-Examination

**Raghunathan → Obi:** "If the hash of the embedding can't be used to train the router, what's the privacy-preserving alternative that still provides training signal?"

**Obi → Raghunathan:** "You can transmit a perturbed embedding: add Gaussian noise at local level before transmission, with the noise calibrated to the L2 sensitivity of the embedding. The server receives a noisy embedding that preserves approximate semantic similarity but cannot be inverted to the original prompt. This is the correct LDP (Local Differential Privacy) approach. It requires more VRAM for the embedding perturbation step but provides both training utility and privacy."

**Okonkwo → Bergström:** "The aggregator security posture — what's the right threat model for a server collecting routing decisions from 5,000 nodes?"

**Bergström → Okonkwo:** "The aggregator should be treated as a high-value honeypot target. It needs: rate limiting per node, signal validation (reject malformed signals), aggregation into time-window buckets (no per-signal queryable state), and a threat model document. This is 4-8 weeks of security-focused infrastructure work."

### Red Team Arguments (MANDATORY)

**Red Team Lead:** Dr. Adaeze Obi

**Obi (RED TEAM):** "I argue against the federated LoRA gradient aggregation component in Wave 4. The gradient inversion risk is real and unmitigated. The masterplan says 'send gradient updates (not data)' as if gradients are safe. They are not. Publishing gradient updates from users' routing decisions could leak the content of those decisions to a sophisticated attacker running gradient inversion. I recommend: (1) defer federated gradient aggregation to Wave 5 or 6 after a formal security audit; (2) use only anonymized aggregate statistics (not gradients) for router model updates in Wave 4."

**Okonkwo (RED TEAM):** "I argue against the current SHA-256(embedding) privacy design as providing false privacy assurance. It does not protect against rainbow table attacks on common prompt patterns. Shipping this and claiming 'prompt content never leaves the device' while the hash can be reverse-engineered for common prompts is a trust violation if discovered. Either implement proper LDP (as Obi described) or don't collect embeddings at all."

**Bergström (RED TEAM):** "I argue against placing collective intelligence in Wave 4 (Weeks 18-26). The infrastructure is underestimated by at least 2×. Placing it here risks delaying Waves 5-6 or forcing an under-engineered collective intelligence launch. Move it to Wave 5-6 with proper scoping. Wave 4 can be goal-based onboarding and unified API alone."

### Vote

| Advisor | Vote | Condition |
|---------|------|-----------|
| Obi | NO-GO | Sensitivity analysis required; k-anonymity k≥500; LDP perturbed embeddings not SHA-256; gradient aggregation deferred |
| Okonkwo | NO-GO | SHA-256 embedding hash replaced with LDP; aggregator security design required |
| Raghunathan | GO WITH CONDITIONS | Embedding approach must be fixed before training signal is useful |
| Vega | GO WITH CONDITIONS | Idempotency protocol for signal batching required |
| Bergström | NO-GO | Wave 4 timeline is unrealistic; move to Wave 5-6 |
| Marchetti | GO WITH CONDITIONS | GDPR lawful basis must be established; right to erasure approach reviewed by EU counsel |
| Nwosu | GO WITH CONDITIONS | Opt-in value exchange redesign required |
| Al-Rashid | GO WITH CONDITIONS | Marketing language must reflect "future moat, not current moat" |
| Kim | GO | |
| Tanaka | GO WITH CONDITIONS | Opt-out mechanism must be in first-run wizard |
| Ibrahim | GO WITH CONDITIONS | Opt-in value exchange must be user-research validated |
| Vega | GO WITH CONDITIONS | |

**Vote result:** 3 NO-GO, 7 GO WITH CONDITIONS, 2 GO | **Threshold for architecture change: 10/12 → FAILS**

**Arbiter Synthesis:** Collective Intelligence as designed does NOT reach the 10/12 threshold required for an architecture change. The design requires significant revision before implementation:
1. Replace SHA-256(embedding) with LDP-perturbed embeddings (Local Differential Privacy)
2. Establish formal ε sensitivity analysis for each signal type
3. Increase k-anonymity minimum to k ≥ 500
4. Defer federated gradient aggregation to Wave 5-6 pending security audit
5. Establish GDPR lawful basis with EU legal counsel review
6. Redesign opt-in value exchange
7. Move Wave 4 timeline to Weeks 24-32 (currently 18-26)

**PQS Impact:** Privacy/Security category scores 48/100 as designed. With conditions met: estimated 72/100.

---

## Topic 3: Wave 5 Fine-Tuning Strategy — RouteLLM + VB-LoRA Viability (#477)

### Arbiter Framing

Wave 5 proposes a LoRA fine-tuning pipeline using Unsloth + PEFT + QLoRA, with GGUF export for deployment. The "proprietary router model moat" uses DPO fine-tuning of Qwen2.5-0.5B on fleet routing decisions. VB-LoRA is mentioned as a future direction.

### Position Statements

**Dr. Rafael Kim (MLOps):** "The LoRA pipeline design is good — Unsloth + PEFT + QLoRA is the correct stack. My concerns are practical: (1) GGUF adapter export compatibility with llmhosts_core's GGUF parser is untested and likely requires separate implementation; (2) the 6-8 hour training estimate for 70B on RTX 4090 is 12-20 hours in practice; (3) VB-LoRA is a research prototype, not a production tool — it should not be mentioned in product plans."

**Dr. Priya Raghunathan (Performance):** "The router model fine-tuning is the most strategically important element. DPO fine-tuning of Qwen2.5-0.5B on routing decisions is technically sound — DPO is appropriate for preference-based routing optimization. The concern is the training data: if collective intelligence data has the LDP-perturbed embeddings we just discussed, the training examples have noisy inputs. Does DPO training on noisy embeddings converge to a better-than-baseline router?"

**Amara Nwosu (Business):** "The LoRA user fine-tuning is a Pro+ feature. The conversion lever — users who invest in fine-tuning their own adapter are unlikely to churn. This is the strongest retention mechanism in the product. I strongly support Wave 5 fine-tuning as a conversion driver. My only concern is that the minimum viable fine-tuning experience (small dataset, fast feedback) must be designed before the full pipeline."

**Dr. Adaeze Obi (Privacy):** "The user fine-tuning pipeline: training data lives locally, adapter lives locally. No privacy concern. The fleet routing data used for router fine-tuning uses anonymized signals — with the LDP corrections we recommended, this is acceptable. One additional concern: when users deploy adapters to marketplace nodes, the adapter itself may leak training data. A company fine-tuned on proprietary documentation creates an adapter that, if interrogated systematically, might reconstruct that documentation. This is a known LoRA risk."

**Elena Marchetti (Legal):** "The 'proprietary router model weights' as a trade secret: model weights trained on user-generated fleet data. If the weights are trained using user data (even anonymized routing decisions), do users have any IP claim on the resulting model? This is an emerging area of law. The terms of service should explicitly address: (1) what users grant LLMHosts when they opt into telemetry; (2) whether the model weights derived from their data can be commercialized by LLMHosts. Most current ToS handle this through a broad license grant, which is legally sound but worth being explicit about."

**Dr. Hans Bergström (Feasibility):** "Wave 5 (Weeks 26-36) includes: full LoRA pipeline with Unsloth backend, GGUF adapter export, benchmark suite publication, and marketplace adapter sharing. That is 3-4 full product features in 10 weeks. Adding the GGUF adapter compatibility testing with llmhosts_core (which Dr. Kim identified as a separate implementation effort) pushes this to 12-16 weeks of work."

### Cross-Examination

**Kim → Raghunathan:** "If LDP-perturbed embeddings are noisy, can the DPO router still learn meaningful routing preferences?"

**Raghunathan → Kim:** "This depends on the noise level. At ε=0.5 with standard Gaussian mechanism on 384-dimensional embeddings, the noise magnitude is substantial. Approximate nearest-neighbor lookup (which is what Tier 1 kNN does) degrades gracefully with noise because the similarity is approximate by design. But DPO fine-tuning is more sensitive to input noise — the preference pairs need to be cleanly separable in the embedding space. This is an empirical question that requires experimentation. I'd recommend a research experiment before committing to this as the training approach."

**Kim → all:** "The GGUF export for LoRA adapters: the masterplan says 'llama.cpp convert_lora_to_gguf.py integration.' This script exists in llama.cpp but it targets a specific GGUF schema for adapters. llmhosts_core's GGUF parser handles base models only. Loading an adapter-GGUF requires either: (a) implementing adapter loading in llmhosts_core's GGUF parser (significant), or (b) pre-merging the adapter into the base model weights and exporting as a new base GGUF (simpler but creates large files). Which approach is planned?"

### Red Team Arguments (MANDATORY)

**Red Team Lead:** Dr. Hans Bergström

**Bergström (RED TEAM):** "I argue against VB-LoRA appearing anywhere in the Vision 2026 document as a planned feature. VB-LoRA is a 2024 NeurIPS paper with 200 GitHub stars. Including it in a product roadmap creates expectations that cannot be met. Remove it from all planning documents and refer to it only as 'future research direction.'"

**Kim (RED TEAM, self):** "I argue against the 6-8 hour training time estimate for 70B QLoRA on RTX 4090. This number will be cited in marketing and will be wrong. Real estimate: 12-20 hours. This will create disappointed users who started a fine-tune expecting 6 hours and are still waiting at hour 14. Either fix the estimate or build the pipeline to show realistic time estimates dynamically (based on actual observed throughput in the first 100 steps)."

**Marchetti (RED TEAM):** "I argue that fine-tuning user data IP rights must be clarified before Wave 5 launches. If a company fine-tunes their private documentation and the adapter is deployed to marketplace nodes (even marked 'private'), that adapter is now running on hardware LLMHosts does not control. If the marketplace node operator extracts the adapter file, they may have access to a compressed form of the company's proprietary knowledge. The 'private' flag is a configuration setting, not an enforcement mechanism."

### Vote

| Advisor | Vote | Condition |
|---------|------|-----------|
| Kim | GO WITH CONDITIONS | GGUF adapter loading in llmhosts_core must be implemented; time estimate corrected to 12-20 hours; VB-LoRA removed |
| Raghunathan | GO WITH CONDITIONS | DPO training on noisy embeddings must be experimentally validated |
| Nwosu | GO | Strong retention driver |
| Bergström | GO WITH CONDITIONS | Wave 5 timeline extended to 12-16 weeks; VB-LoRA removed |
| Marchetti | GO WITH CONDITIONS | IP rights terms of service clarification before launch |
| Obi | GO WITH CONDITIONS | Adapter data leakage risk documented in user-facing security docs |
| Al-Rashid | GO | |
| Tanaka | GO WITH CONDITIONS | Show real-time training progress and dynamic time estimate |
| Ibrahim | GO | |
| Okonkwo | GO WITH CONDITIONS | Adapter file integrity checks required for marketplace |
| Vega | GO | |
| Boateng | GO | |

**Vote result:** 10 GO or GO WITH CONDITIONS, 2 GO WITH CONDITIONS (all conditions) | **Threshold: 8/12 → PASSES**

**Arbiter Synthesis:** Wave 5 Fine-Tuning passes with conditions: (1) VB-LoRA removed from all roadmap documents; (2) training time estimate corrected to 12-20 hours with dynamic estimation; (3) GGUF adapter loading implemented in llmhosts_core before Wave 5 launch; (4) ToS IP rights clarification; (5) Wave 5 timeline extended.

---

## Topic 4: IP Protection Strategy — "Native Acceleration Layer" Vocabulary

### Arbiter Framing

Section 8 proposes approved marketing vocabulary that obscures technical dependencies. Key claim: Cargo.toml crate naming can obscure CubeCL usage. The question: does the IP strategy actually hold against determined competitor analysis?

### Position Statements

**Elena Marchetti (Legal):** "The vocabulary guide in Section 8.2 is professionally correct — this is standard IP communication strategy. 'Cross-platform GPU compute' instead of 'CubeCL' is appropriate and not misleading. However, the trade secret strategy has two fundamental failures: (a) the Cargo.lock in the published wheel reveals exact crate versions including CubeCL version numbers; (b) no trade secret register has been established, which is a prerequisite for trade secret legal protection."

**Marcus Okonkwo (Security):** "Wheel inspection is a 5-minute exercise. `pip download llmhosts && unzip llmhosts-*.whl && cat llmhosts-0.5.1.dist-info/RECORD`. The record file lists all files including compiled binaries with their hashes. The Cargo.lock file embedded in the wheel (if present) shows every dependency. Even if not, `strings _llmhosts_core.so | grep -i cubecl` will likely find version strings in the binary. The 'obscure by crate name' strategy provides approximately 30 minutes of obfuscation to a motivated engineer."

**Dr. Priya Raghunathan (Performance):** "The performance is the IP. If CubeCL gives us 85% of CUDA performance with cross-platform support, the value is the result, not the implementation. A competitor who knows we use CubeCL still needs to implement everything we've implemented. The vocabulary guide should focus on protecting the router model weights and the HIM data — those are genuinely hard to replicate — not the compute backend choice."

**Fatima Al-Rashid (Competitive):** "The IP protection strategy is solving the wrong problem. Our moat is not 'competitors don't know we use CubeCL.' Our moat is 'competitors can't build the collective intelligence dataset we have.' The vocabulary guide is marketing polish; the real IP protection is competitive speed advantage. I recommend deprioritizing IP vocabulary and focusing on accelerating the collective intelligence data accumulation."

**Dr. Hans Bergström (Feasibility):** "BSL licensing is the most complex element of the IP strategy. Writing a BSL license that has enforceable 'competing use' provisions requires experienced IP counsel. The document drafts this in prose but a real BSL needs: (a) precise definition of 'competing product,' (b) definition of 'Competitive Use' and what thresholds trigger it, (c) explicit carveouts for non-commercial use, research, education. This is 4-6 weeks of legal work, not a document section."

### Red Team Arguments

**Red Team Lead:** Fatima Al-Rashid

**Al-Rashid (RED TEAM):** "I argue that BSL licensing is net-negative for LLMHosts at this stage. The community LLMHosts needs (developers who share our tool, fork it, contribute issues, write tutorials) is exactly the community that is most sensitive to non-permissive licensing. Apache 2.0 or MIT for the inference engine will result in 3-5× more GitHub stars, more contributors, and more adoption in the first 12 months. The moat from 12 months of adoption data is more valuable than the theoretical protection of BSL against a competitor who hasn't materialized yet."

**Marchetti (RED TEAM):** "I argue that the BSL strategy cannot be implemented without proper legal counsel, and proper legal counsel should happen before Wave 6, not during it. If LLMHosts launches the inference engine as Apache 2.0 and then converts to BSL 18 months later, that conversion will cause a community backlash worse than starting with BSL (HashiCorp evidence). Either commit to BSL from the start with proper legal support, or commit to Apache 2.0 with no conversion plan."

**Okonkwo (RED TEAM):** "I argue that the wheel inspection trade secret claim creates legal liability: if LLMHosts claims trade secret protection on CubeCL usage but takes no reasonable precautions beyond crate renaming, and then sues a competitor for trade secret misappropriation, the court will ask 'what reasonable precautions were taken?' The answer 'we renamed the crate' is not a reasonable precaution. This means the trade secret claim is likely not maintainable, but the attempt to make it creates a false impression of protection."

### Vote

| Advisor | Vote | Condition |
|---------|------|-----------|
| Marchetti | NO-GO (BSL) | BSL requires legal counsel before implementation; recommend Apache 2.0 initially |
| Al-Rashid | NO-GO (BSL) | Apache 2.0 is better business strategy at this stage |
| Nwosu | NO-GO (BSL) | Community moat > trade secret moat for year 1 |
| Okonkwo | GO WITH CONDITIONS | Trade secret register must be established; Cargo.lock must be stripped from wheel |
| Raghunathan | GO (vocabulary guide) | Router model weights as trade secret is the real value |
| Kim | GO WITH CONDITIONS | |
| Tanaka | GO (vocabulary guide) | |
| Ibrahim | GO (vocabulary guide) | |
| Vega | GO WITH CONDITIONS | |
| Boateng | GO WITH CONDITIONS | |
| Bergström | GO WITH CONDITIONS | Legal counsel required before BSL implementation |
| Obi | GO WITH CONDITIONS | |

**Vote (BSL specifically):** 3 NO-GO, majority conditions favor NOT doing BSL at launch
**Vote (vocabulary guide):** 10 GO or GO WITH CONDITIONS

**Arbiter Synthesis:** The vocabulary guide (Section 8.2) passes and is a good practice. BSL licensing does NOT reach consensus — 3 NO-GOs and strong conditional support for Apache 2.0 at launch. The council recommends:
- Launch inference engine under Apache 2.0
- Router model weights remain proprietary (not covered by Apache 2.0)
- HIM dataset remains proprietary
- Establish formal trade secret register with legal counsel for remaining proprietary elements
- Do not convert to BSL without a full community and legal strategy (minimum 18 months from GA)

---

## Topic 5: The 90-Second Install Claim — Realistic or Credibility Risk?

### Arbiter Framing

Section 9.2 (Stage 2: Install) and multiple marketing references claim "< 30 seconds on fast connection (core wheel)." The setup completion time is "< 10 minutes... excluding model download." A 26 GB model download at 100 Mbps takes 34 minutes. Is "90-second install" an accurate marketing claim?

### Position Statements

**Yuki Tanaka (DX):** "The 90-second claim refers to `pip install llmhosts` — the install of the package. This is legitimately achievable on a fast connection if the wheel is binary-only (no compilation). That's accurate for a pre-compiled maturin wheel. But no user's journey ends with `pip install`. The next step is `llmhosts setup` which includes model download. The '90-second install' framing is accurate but creates a false impression. Marketing that doesn't manage the model download expectation sets users up for disappointment."

**Marcus Okonkwo (Security):** "The PTX compilation on first CUDA kernel invocation: if LLMHosts ships CUDA PTX IR in the wheel (not pre-compiled .cubin), the CUDA driver compiles it on first run. This takes 30-60 seconds per kernel variant. The 'first inference' could include a 3-5 minute compile step. This is not counted in any of the marketing time claims."

**Amara Nwosu (Business):** "I want to defend the 90-second install claim strategically. Every developer tool in history has published its best-case install time. Stripe's 'integrate in 10 lines of code' applies to the simplest integration. The 90-second claim is defensible as the install time for the package itself. We should add a parenthetical: '90-second install + model download (26 GB, ~35 min on 100 Mbps).' This is transparent without losing the power of the headline number."

**Dr. Hans Bergström (Feasibility):** "Marketing time claims that are technically accurate but practically misleading create a negative retention event at the exact moment you want to maximize first impression. The first-run experience is when trust is established. If a user installs in 90 seconds and then waits 45 minutes for a model while wondering if something broke — that's a churn risk, not a delight moment."

**Fatima Al-Rashid (Competitive):** "Ollama's install takes ~30 seconds including the default model pull for the first interaction. `ollama run llama3` in one command. LLMHosts' install + setup + download is legitimately longer but has more features. The right framing is not 'install in 90 seconds' but 'from zero to production-grade AI infrastructure in one afternoon.' That's accurate and more compelling than a number that requires asterisks."

### Red Team Arguments

**Red Team Lead:** Yuki Tanaka (against the 90-second claim)

**Tanaka (RED TEAM):** "I argue that the 90-second claim should be abandoned or significantly qualified. The reason: every time a user sees '90 seconds' in marketing and their actual experience is '45 minutes,' they feel deceived — even if the 90-second claim was technically accurate. The trust deficit this creates is worse than the marketing benefit of the claim. Alternative: 'One command to install, 10 minutes to first inference on your own hardware.' This is accurate, impressive, and doesn't create false expectations."

**Bergström (RED TEAM):** "I argue the current install flow cannot achieve 90 seconds reliably on non-NVIDIA hardware. AMD ROCm users face driver detection that can take 30+ seconds alone. Intel Arc users may face Level Zero loader not found. These failures don't fail in 90 seconds — they fail in 90 seconds and then require 30 minutes of debugging. '90 seconds or your money back' is not a promise a solo engineer can honor."

### Vote (Binary: Keep or Revise the 90-second claim)

| Advisor | Vote |
|---------|------|
| Tanaka | REVISE |
| Bergström | REVISE |
| Al-Rashid | REVISE |
| Okonkwo | REVISE (add PTX compile caveat) |
| Nwosu | KEEP (with parenthetical) |
| Raghunathan | REVISE (the claim is technically misleading) |
| Kim | REVISE |
| Vega | REVISE |
| Ibrahim | REVISE |
| Boateng | REVISE |
| Marchetti | NEUTRAL (not a legal issue) |
| Obi | NEUTRAL |

**Vote: 8 REVISE, 1 KEEP with parenthetical, 2 Neutral**

**Arbiter Synthesis:** The 90-second claim should be revised. Recommended language: **"One command to install. First inference in < 10 minutes (model pre-downloaded) or 35-60 minutes on a fresh machine."** The emphasis should be on total time-to-value, not package install time. The new north star metric: **"Time from `pip install llmhosts` to first successful inference token."**

---

## Topic 6: Competitive Moat vs. SaladCloud / Vast.ai

### Arbiter Framing

The masterplan claims LLMHosts wins against SaladCloud because "the operator experience is an installable product, not a dashboard." SaladCloud has 60,000 consumer GPUs. How durable is this moat?

### Position Statements

**Fatima Al-Rashid (Competitive):** "SaladCloud's CLI tool timeline: I model this at 55% probability within 18 months, not 20% as stated. SaladCloud's engineering team has the capability and their investors are pushing them toward more developer-facing products. The 'operator experience' moat is a timing advantage, not a structural advantage. The structural moat is: LLMHosts owns the device, not just the API key. SaladCloud owns the platform. This is a fundamentally different operator relationship."

**Amara Nwosu (Business):** "The competitive moat argument misses the strongest actual moat: LLMHosts operators use their own hardware and keep it when they stop using LLMHosts. Their GPU isn't locked in to our platform — they can leave with their hardware. This is paradoxically a trust advantage: 'We don't hold your GPU hostage.' SaladCloud's operators have their GPUs locked into SaladCloud's infrastructure. Emphasize this freedom in marketing."

**Dr. Santiago Vega (Distributed):** "The relay is a real moat that's understated. SaladCloud has no encrypted relay for operators to access their own hardware remotely. The relay creates an operator use case (remote access to my home GPU) that SaladCloud physically cannot match without shipping hardware to users. This is the stickiest moat in the product."

**Fatima Al-Rashid:** "Second point: the collective intelligence data moat is real at scale but requires 2-3 years to compound to meaningful advantage. The 12-month roadmap needs an intermediate moat. I propose: the Hardware Intelligence Matrix, even with 500 nodes, provides model recommendations that are more accurate than any individual user's experience and better than anything Ollama or SaladCloud offers. This is differentiable within 6 months."

**Marcus Okonkwo (Security):** "Vast.ai's competitive position is weaker than SaladCloud's for LLMHosts. Vast.ai is B2B focused (enterprise GPU compute). Their users are ML engineers buying spot GPU time, not developers running their own hardware. LLMHosts doesn't compete with Vast.ai's user segment."

### Red Team Arguments

**Red Team Lead:** Dr. Hans Bergström

**Bergström (RED TEAM):** "I argue that the competitive moat analysis understates the existential risk from llama.cpp's trajectory. llama.cpp has 70K+ GitHub stars, a highly active contributor community, and is the underlying inference engine for Ollama, LM Studio, GPT4All, and others. If llama.cpp ships a built-in relay, marketplace, and router in the next 12 months (which is not outside their community's capability), every wrapper built on top of it gets those features for free. LLMHosts' moat is not against llama.cpp — it IS llama.cpp for the inference layer. Our moat must be everything above the inference layer: tunnel, marketplace, router, collective intelligence."

**Al-Rashid (RED TEAM):** "I argue that 'We are 2-5× faster on the same hardware' is not a durable moat for the SaladCloud comparison. SaladCloud's advantage is scale — they have 60K GPUs. LLMHosts starts with zero marketplace supply. The performance claim is a device-operator recruitment argument, not a competitive positioning against SaladCloud's existing customers."

### Votes (competitive moat is adequately defined)

| Advisor | Vote | Condition |
|---------|------|-----------|
| Al-Rashid | GO WITH CONDITIONS | Moat hierarchy must be redefined: relay first, HIM second, collective intelligence third |
| Nwosu | GO WITH CONDITIONS | "Operator freedom" messaging should be primary vs. "we're faster" |
| Raghunathan | GO WITH CONDITIONS | Performance moat is temporary; cross-platform is the durable moat |
| Bergström | GO WITH CONDITIONS | llama.cpp trajectory must be explicitly modeled in risk matrix |
| Vega | GO | Relay is the strongest near-term structural moat |
| Okonkwo | GO | |
| Tanaka | GO | |
| Ibrahim | GO | |
| Kim | GO | |
| Boateng | GO | |
| Marchetti | GO | |
| Obi | GO | |

**Vote: 10 GO, 2 GO WITH CONDITIONS → PASSES**

**Arbiter Synthesis:** Competitive positioning passes. Conditions: (1) Moat hierarchy reframed as relay → HIM → collective intelligence → performance; (2) SaladCloud comparison must acknowledge timing risk (not 20%, more like 50%); (3) llama.cpp added to risk matrix as a new R11 risk.

---

## Overall PQS Assessment — Vision 2026 Design (Pre-Implementation)

### Category Scores

**Methodology:** Each advisor scored the Vision 2026 DESIGN (not current implementation) against their category sub-dimensions. MEDIAN aggregation. Current state scores what EXISTS; planned state scores the design on its merits.

#### Category 1: Inference Engine Quality (Current State)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Raghunathan | 38/100 | CUDA kernels not implemented; no continuous batching; Mutex<Option<model>> blocking |
| Boateng | 42/100 | GGUF parsing good; quantization working; GPU not yet accelerated |
| Bergström | 40/100 | Architecture correct; concurrency design missing; GIL management unaddressed |

**Median: 40/100 | Weight: 20% | Contribution: 8.0**
**Hard Gate: ≥ 60 | Status: FAIL**

#### Category 1: Inference Engine Quality (Vision 2026 Design Potential)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Raghunathan | 72/100 | Flash Attention + CUDA path credible; cross-platform via CubeCL plausible; timeline aggressive |
| Boateng | 68/100 | NVIDIA solid; Apple Metal gap via WGPU; AMD ROCm consumer risk |
| Bergström | 65/100 | Design is correct; feasibility risk on timeline |

**Median: 68/100 | Weight: 20% | Contribution: 13.6 (Vision Design)**

#### Category 2: Cross-Platform GPU Support (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Boateng | 52/100 | NVIDIA 90%; Apple Metal 60-65% via WGPU; AMD 70-80%; Intel 40-70% |
| Raghunathan | 55/100 | Feasibility concerns on 4-platform simultaneous commitment |

**Median: 53/100 | Weight: 10% | Contribution: 5.3**

#### Category 3: Developer Experience & Onboarding (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Tanaka | 65/100 | Goal-based wizard excellent; AMD/Intel failure paths undefined; model download UX unspecified |
| Ibrahim | 60/100 | Journey map good; retention arc gaps; operator waiting period not addressed |

**Median: 63/100 | Weight: 15% | Contribution: 9.4 (Vision Design)**
**Hard Gate: ≥ 55 | Status: PASS (Vision Design)**

#### Category 4: Privacy & Security Architecture (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Obi | 48/100 | k-anonymity too small; ε unjustified; gradient leakage; SHA-256 hash insufficient |
| Okonkwo | 45/100 | Marketplace prompt exfiltration risk; aggregator security undefined; GGUF download trust |

**Median: 46/100 | Weight: 15% | Contribution: 7.0**
**Hard Gate: ≥ 65 | Status: FAIL**

#### Category 5: Business Model & Competitive Position (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Nwosu | 62/100 | PLG motion correct; BSL risk; revenue targets aggressive; marketplace liquidity challenge |
| Al-Rashid | 58/100 | Window is real but tighter than claimed; Ollama catch-up timeline underestimated |

**Median: 60/100 | Weight: 15% | Contribution: 9.0**

#### Category 6: Distributed Systems & Reliability (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Vega | 55/100 | Relay protocol sound; Noise NK not yet implemented; thundering herd; no multi-region |
| Bergström | 50/100 | Engineering capacity risk; Mutex concurrency issue; GIL management |

**Median: 53/100 | Weight: 10% | Contribution: 5.3**
**Hard Gate: ≥ 55 | Status: FAIL (Vision Design is below hard gate)**

#### Category 7: IP Strategy & Legal Soundness (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Marchetti | 42/100 | Trade secret register absent; BSL requires legal counsel; Llama license gap; GDPR right to erasure |

**Score: 42/100 | Weight: 5% | Contribution: 2.1**

#### Category 8: Fine-Tuning Pipeline Viability (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Kim | 55/100 | Stack correct; GGUF adapter compatibility gap; training time wrong; VB-LoRA premature |

**Score: 55/100 | Weight: 5% | Contribution: 2.75**

#### Category 9: Engineering Feasibility (Vision Design)

| Advisor | Score | Key Evidence |
|---------|-------|-------------|
| Bergström | 40/100 | 48-week roadmap is 2× undersized; Mutex rework not planned; GIL unaddressed |
| Vega | 45/100 | Relay M2-M5 feasibility tight; single-threaded inference blocks Wave 1 GPU milestone |

**Median: 43/100 | Weight: 5% | Contribution: 2.1**

---

### Project Quality Scorecard — Vision 2026 Design

| Category | Weight | Design Score | Contribution | Hard Gate | Status |
|----------|--------|-------------|--------------|-----------|--------|
| Inference Engine Quality | 20% | 68 | 13.6 | ≥60 | PASS |
| Cross-Platform GPU | 10% | 53 | 5.3 | N/A | — |
| Developer Experience | 15% | 63 | 9.4 | ≥55 | PASS |
| Privacy & Security | 15% | 46 | 7.0 | ≥65 | **FAIL** |
| Business Model | 15% | 60 | 9.0 | N/A | — |
| Distributed Systems | 10% | 53 | 5.3 | ≥55 | **FAIL** |
| IP Strategy | 5% | 42 | 2.1 | N/A | — |
| Fine-Tuning | 5% | 55 | 2.75 | N/A | — |
| Engineering Feasibility | 5% | 43 | 2.1 | N/A | — |
| **PQS** | **100%** | | **56.5/100** | | **2 HARD GATES FAIL** |

**PQS: 56.5/100 — "Below standard — major gaps"**

**Hard Gate Status: 2 FAILURES (Privacy/Security, Distributed Systems)**

---

## Interpretation

**PQS 56.5/100** places Vision 2026 design in the "Below standard — major gaps" range. This does NOT mean the vision should be abandoned — it means the design has critical gaps that must be resolved before implementation begins.

The two hard gate failures are the most critical findings:
1. **Privacy & Security (46/100, gate requires 65):** The collective intelligence privacy design, marketplace prompt exfiltration risk, and GDPR compliance gaps are design-level failures that could be existential if uncorrected.
2. **Distributed Systems (53/100, gate requires 55):** The relay encryption gap (Noise NK not implemented but marketed as complete), thundering herd risk, and single-threaded inference engine are near-term blockers.

If the council's conditions from Topics 1-6 are all met, the estimated revised PQS would be approximately **71-74/100** ("Solid — functional but notable gaps"). That is the realistic ceiling given the single-engineer capacity constraint and the 12-month timeline.

---

## Final Advisory Council Recommendations (Priority Order)

### P0 — Existential (Block Vision 2026 unless resolved)

1. **[GAP-01] Privacy/Security Score: 7/10 severity** — Redesign collective intelligence privacy model: replace SHA-256(embedding) with LDP-perturbed embeddings; establish formal ε sensitivity analysis; k-anonymity k≥500; defer federated gradient aggregation.

2. **[GAP-02] Relay Encryption Gap: 9/10 severity** — Remove all "encrypted with Noise NK" language from marketing until Noise NK is implemented (M2). Current relay is WSS without application-layer encryption. This is an active trust violation in current marketing.

3. **[GAP-03] Concurrent Inference Architecture: 8/10 severity** — Replace `Mutex<Option<model>>` with async-safe concurrent design before Wave 1 GPU compute milestone. Without this, "continuous batching" cannot be implemented and the performance claims are unmeetable.

### P1 — Critical (Resolve in Wave 1-2)

4. **[GAP-04] GIL Management in pyo3 Bridge: 8/10 severity** — Long-running Rust generation calls hold the Python GIL, blocking all other FastAPI request processing. `py.allow_threads()` must wrap all blocking Rust calls.

5. **[GAP-05] 90-Second Install Claim: 7/10 severity** — Replace with honest timeline: "One command. First inference in < 10 minutes (model pre-downloaded) or 35-60 minutes (first-time setup including model download)."

6. **[GAP-06] Cross-Platform Performance Honesty: 7/10 severity** — Apple Silicon via CubeCL/WGPU is 50-65% of Ollama's Metal performance (which uses MPS). AMD ROCm consumer cards are 60% failure likelihood. Marketing must be platform-specific.

7. **[GAP-07] VB-LoRA Removal: 6/10 severity** — Remove VB-LoRA from all planning documents. It is a 2024 NeurIPS research prototype with 200 GitHub stars. Its presence in the roadmap creates undeliverable expectations.

8. **[GAP-08] GGUF Adapter Loading: 6/10 severity** — llmhosts_core's GGUF parser handles base models only. LoRA adapter GGUF format requires separate implementation. This must exist before Wave 5 fine-tuning launch.

### P2 — Important (Resolve in Wave 2-4)

9. **[GAP-09] BSL Licensing Strategy: 8/10 severity** — Council recommends against BSL at launch. Apache 2.0 for inference engine; proprietary for router model weights and HIM data. BSL conversion (if pursued) requires experienced IP counsel minimum 18 months from GA.

10. **[GAP-10] Thundering Herd in Relay Reconnect: 6/10 severity** — Add jitter to reconnection backoff. At 10K nodes reconnecting simultaneously, the current design creates a reconnection storm that could extend outages.

11. **[GAP-11] GDPR Lawful Basis for Collective Intelligence: 7/10 severity** — Opt-out is not a sufficient lawful basis for collective intelligence signal collection under GDPR. EU legal counsel review required before Wave 4 launch.

12. **[GAP-12] Training Time Estimate Corrections: 5/10 severity** — 70B QLoRA on RTX 4090 training time is 12-20 hours, not 6-8 hours. Correct in all documentation.

13. **[GAP-13] Aggregator Security Design: 7/10 severity** — The collective intelligence aggregator is an undesigned high-value attack target. Security design document required before Wave 4 implementation begins.

14. **[GAP-14] Llama 3 License Compliance: 6/10 severity** — Marketplace nodes serving Llama 3.3 inference at commercial scale may require explicit compliance review against Meta's Llama 3 Community License. Legal review before marketplace GA.

15. **[GAP-15] GGUF Download Trust: 5/10 severity** — registry.py trusts third-party HuggingFace uploaders (e.g., "bartowski"). Add SHA-256 checksum verification from a LLMHosts-controlled manifest before download.

### P3 — Recommended (Resolve in Wave 3-6)

16. **[GAP-16] llama.cpp Trajectory in Risk Matrix: 5/10 severity** — llama.cpp (70K stars, active community) could ship relay + marketplace + router equivalent in 12-18 months. Add as R11 to risk matrix.

17. **[GAP-17] Operator Waiting Period: 4/10 severity** — Stage 8 (Marketplace Operator) has a weeks-long feedback gap before first payout. Design intermediate feedback moments (first booking notification, estimated first payout date) to prevent dropout.

18. **[GAP-18] Hatchling Hook Security Model: 6/10 severity** — The pre-install GPU detection hook runs arbitrary code at pip install time. Formal security model and minimal code surface required.

19. **[GAP-19] Model Download Resume Capability: 4/10 severity** — 26 GB downloads on residential connections fail and cannot be resumed. Implement chunked download with resume from offset.

20. **[GAP-20] HIM Cold-Start Data Volume: 5/10 severity** — The HIM provides no advantage until 500+ opt-in nodes contribute data. Cold-start should use only LLMHosts' own benchmark data; marketing should not imply fleet-powered recommendations until the threshold is reached.

---

## Session Close

**Arbiter Statement:**

This council has identified 20 gaps across 6 debate topics. The Vision 2026 design is ambitious, credible in its overall direction, and built on a solid foundation (working CPU inference, production Python proxy, tested marketplace). The gaps identified are real and actionable — none are existential to the vision itself.

The two findings the council considers most urgent:

**Finding 1 — The relay encryption claim (GAP-02):** The current v0.5.1 release markets a relay with Noise NK encryption that has not been implemented. This is the highest single credibility risk in the product. It must be corrected immediately in marketing copy.

**Finding 2 — The concurrency architecture (GAP-03):** The `Mutex<Option<model>>` design prevents concurrent request processing. Building "continuous batching" on top of this architecture is impossible without first replacing it. This should be the first engineering action before any Wave 1 GPU compute work begins.

If the top 3 P0 gaps are resolved and the P1 gaps are addressed in Waves 1-2, the council projects a revised PQS of 71-74/100 — a solid foundation for the Vision 2026 launch.

**Next session:** Recommended for 90 days from today (2026-06-10) to assess Wave 1 and Wave 2 progress against the gap resolutions.
