← Back to library

I Replaced Claude Design… 100% UNLIMITED — technical analysis

Watch videoView transcript

Jack Roberts15:53Transcript ✅Added May 20, 10:40 am GMT+8

Video: https://www.youtube.com/watch?v=ju-T6uQNPSg
Creator: Jack Roberts
Duration: 15:53
Primary tool: nexu-io/open-design
Short verdict: Open Design is a real, fast-moving local-first alternative to Claude Design for agent-driven prototypes, decks, dashboards, and brand-styled HTML artifacts. The video’s workflow is useful, but the headline claims need tightening: it is not automatically “100% local” if you use hosted CLIs/APIs, not truly “unlimited/free,” and Apache-2.0 is commercially friendly but not a blanket IP/legal guarantee.

Actionable insights for technical users

  1. Pilot Open Design as a local artifact-generation workbench, not as a drop-in replacement for a design team.
    Start with the official repo and docs: nexu-io/open-design and QUICKSTART.md. The current repo describes itself as a local-first, BYOK, multi-model alternative to Claude Design/Figma, with coding-agent CLIs auto-detected on PATH, built-in skills, design systems, sandboxed preview, and HTML/PDF/PPTX/ZIP-style exports. A safe first experiment is a single non-client internal prototype: clone the repo, run it locally, generate one dashboard or landing page, export HTML, then review the output like any generated code.

    git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable
pnpm install
pnpm tools-dev run web
# open the printed local URL, often localhost-based

    Evaluate it with a simple scorecard: visual polish, brand consistency, accessibility basics, responsiveness, generated code quality, export fidelity, and number of manual edits required before it can enter a real repo. Treat anything under “pretty demo” quality as ideation material, not production UI.

  2. Use a two-model workflow: strongest design model for first draft, cheaper/faster models for iteration.
    The creator’s best practical advice is at 8:10–8:41: use Claude/Opus-like quality for the initial visual architecture, then switch to Codex, Gemini, OpenCode/OpenRouter, or another model for smaller edits once the design grammar exists. This is a sensible cost-control pattern because later requests are constrained by an existing file, palette, layout, and component structure.

    Suggested operating loop:

    • Generate first draft with your best frontend/design model.
    • Save/export the artifact immediately.
    • Switch to a cheaper model for narrow edits: “smooth the live event stream animation,” “tighten spacing,” “make the empty state accessible,” “remove decorative gradients.”
    • Run a deterministic review step with another model or a human: accessibility, responsive behavior, HTML/CSS quality, dependency risk, and brand fit.

    Success metric: the cheaper model should improve or maintain the artifact without introducing layout regressions. If it repeatedly breaks composition, keep it for copy/code cleanup only.

  3. Decide upfront whether your run is actually local, BYOK-cloud, or subscription-cloud.
    The video repeatedly says “local” and “nothing uploads” around 3:04 and 7:08. That is only fully true for the Open Design app/daemon/project files and any truly local model/runtime you run yourself. If you select Claude Code, Codex, Gemini, OpenRouter, Anthropic API, OpenAI image generation, Vercel deployment, or another hosted provider, prompts, generated code, images, and metadata may leave your machine according to that provider’s policies.

    Add this checklist before client use:

    • Which execution mode is selected: local CLI, Anthropic API, OpenAI API, Google Gemini, OpenRouter/OpenCode, Ollama, etc.?
    • Are prompts, screenshots, brand assets, repository files, or client secrets sent to a cloud model?
    • Are API keys stored in environment variables or pasted into the app settings? Who can read them?
    • Is the generated artifact deployed to Vercel or only exported locally?
    • Are logs, .od SQLite state, artifacts, and imported ZIPs excluded from public commits?

    Practical rule: call it local-first, not 100% local, unless you can prove every model and media generator is running locally and no external deploy/share action is used.

  4. Verify Node/pnpm compatibility before blaming the model.
    The top technical comment reports a “Daemon is offline” failure tied to better-sqlite3 and Node 24, with a workaround using Node 22 portable inside the Open Design directory. However, the current Open Design QUICKSTART.md says the repo requires Node ~24 and pnpm@10.33.2. That means the comment is valuable field evidence but may reflect an earlier commit, OS-specific native-module issue, or mismatch between global and project Node versions.

    Recommended troubleshooting sequence:

    node -v
corepack pnpm --version
pnpm tools-dev check
pnpm tools-dev logs
pnpm --filter @open-design/daemon build
pnpm tools-dev restart

    If native modules fail, try a clean install, confirm the pinned pnpm version, and only then test the commenter’s Node 22 workaround in an isolated shell or container. Do not downgrade your whole workstation just for one repo.

  5. Add a repo-safety gate before cloning/running trending AI tools.
    One commenter asks the right question: “Are there any risks of downloading repos like this locally?” Yes. Open Design is an active Node/Electron/daemon-style project with postinstall scripts, native modules, local file access, agent spawning, API keys, and optional deploy integrations. That is powerful and risky.

    Minimal pre-run checklist:

    git clone https://github.com/nexu-io/open-design.git
cd open-design
git log --oneline -5
cat package.json | sed -n '1,160p'
grep -R "postinstall\|curl\|child_process\|exec(\|spawn(" -n package.json scripts apps | head -80
pnpm install --ignore-scripts   # optional first inspection pass
pnpm audit                     # useful but not sufficient

    For client work, prefer running it in a devcontainer, VM, Docker mode, or non-admin user account. Never paste production API keys or private client assets into a newly cloned tool until you have reviewed its data flow.

  6. Treat Apache-2.0 as a good license signal, not a complete commercial clearance.
    Open Design’s repo metadata and license file identify Apache License 2.0. Apache-2.0 grants broad rights to use, modify, distribute, sublicense, and sell the software, plus a patent license from contributors, subject to notice/license obligations. That supports commercial use of the Open Design software itself.

    But it does not automatically clear:

    • trademark use of brands like Apple, Stripe, Vercel, Nike, PlayStation, etc.;
    • copyright/trade-dress concerns if outputs intentionally mimic a brand too closely;
    • rights in third-party design-system source repos or bundled assets beyond their licenses;
    • rights in AI-generated images produced by external models;
    • client confidentiality/data-processing obligations.

    Operational takeaway: Apache-2.0 makes Open Design much safer to adopt than a non-commercial repo, but production/client outputs still need legal/design review when they imitate named brands.

  7. Use OpenRouter/OpenCode for model breadth, but budget for limits and variance.
    The video’s free-model path uses OpenRouter via OpenCode-like routing at 11:42–13:14. OpenRouter’s own FAQ says it provides a unified API to many models, passes through provider pricing, uses credits, and has :free variants with low rate limits. It also states free-model rate limits depend on credits purchased: users with at least $10 in credits get a higher daily free-model limit; otherwise the cap is lower. This directly contradicts any literal “unlimited/free” reading.

    Good experiment:

    • Pick one artifact and run three edit passes: Claude/Opus or Sonnet, GPT/Codex, and one OpenRouter free/low-cost model.
    • Measure: edit success rate, visual regressions, latency, cost, and number of repair prompts.
    • Keep a design-eval.md file beside the artifact with screenshots, prompts, model names, and verdicts.

    Use free models for exploration or low-risk variations. Use paid/reliable models for first-pass visual hierarchy and final code review.

Core thesis

The video argues that Claude Design’s visual artifact workflow is valuable, but its limits and closed Anthropic-only model path are constraining; Open Design recreates much of the workflow locally and lets users route design generation through whatever coding agents, APIs, and model providers they already use.

My read: the thesis is directionally right. Open Design is credible because it does not merely wrap a prompt; it provides a local daemon, project persistence, design systems, skills, discovery forms, previews, export flows, and coding-agent integration. The creator overstates the absolutes—“100% local,” “100% unlimited,” “free,” and “safe for clients”—but the underlying workflow is genuinely useful for technical operators who can vet code, manage model routing, and review generated artifacts.

Big ideas and key insights

  • Artifact-first design is becoming a coding-agent workflow. Claude Design, Open Design, Antigravity, Claude Code, OpenCode, and Codex-style tools all converge on the same loop: brief → clarify → generate files/artifact → preview → iterate → export/deploy.
  • The model is only part of the product. Open Design’s value is the scaffolding around the model: design systems, skills, preview sandbox, project state, import/export, and model switching.
  • Multi-model routing is practical. Use the best model for first principles and cheaper/specialized models for edits, image generation, critique, or export polishing.
  • Brand-system imitation is both feature and risk. “Apple/Stripe/Vercel style” prompts are powerful internally, but commercial outputs must avoid confusingly close copies.
  • Local-first tools still have cloud edges. A local UI can call hosted model CLIs, remote APIs, image models, OpenRouter, and Vercel. Data-flow diagrams matter.
  • Community comments surfaced real implementation issues. Node/native-module setup, stale local servers, model switching confusion, Claude credit burn, and quality gaps are more operationally useful than the hype.

Best timestamped moments with interpretation

  • 0:00–0:21 — The headline claim. Open Design is introduced as a Claude Design clone that is “100% local” and can be used with any model, even free. This frames the opportunity but also sets up the most overclaimed parts of the video.
  • 1:31–2:02 — Claude Design pain points. The creator cites usage caps, AI-looking output, Anthropic lock-in, and one-model limitation. These complaints match comments from viewers who max out Claude frequently, but the exact “one meaningful project a week” claim is anecdotal.
  • 2:02–3:04 — Apache-2.0 and brand systems. The most important factual claim: Open Design has an Apache-2.0 license and built-in brand/design systems. GitHub metadata supports the Apache-2.0 claim; the commercial interpretation needs caveats.
  • 3:34–4:34 — Clone/open/run workflow. The creator asks Antigravity to clone the repo and open it. This shows the new meta-workflow: use one agentic IDE to install and operate another agentic design tool.
  • 5:04–5:35 — Execution mode selection. The Open Design setup screen shows local CLI and API options, with Claude Code selected. This is where “local” becomes conditional: the UI is local, but the selected execution backend may be cloud-backed.
  • 5:35–6:36 — Discovery form and prompt shaping. The creator defines an analytics dashboard, audience, tone, visual references, density, animation, and wow moment. This is the replicable part: forcing a structured brief before generation.
  • 7:08–8:10 — One-shot dashboard and model switching. The demo shows an interactive dashboard, then switches from Claude Code to Codex/ChatGPT-style execution for a refinement. The workflow is valuable even if the output quality is not independently benchmarked.
  • 8:10–8:41 — Best tactical advice. “Use Opus/Claude to get the initial design, then tag in other models.” This is the most transferable operator pattern in the video.
  • 9:11–9:42 — Export/deploy options. Export to PDF/PPT/ZIP/standalone HTML and deploy to Vercel are presented. This matters because artifact generation only becomes useful when it enters a delivery channel.
  • 10:12–11:42 — Image generation integration. The creator adds an OpenAI image key and asks for a Ghibli-style piggy-bank image. The integration story is strong, but it also breaks any strict local-only/privacy claim.
  • 11:42–13:14 — OpenRouter/OpenCode free-model path. Useful as a model-router pattern, but “free” depends on provider limits, account credits, and model availability.
  • 14:14–15:14 — Who should use or skip it. The creator correctly says it suits agencies, freelancers, multi-model operators, and people hitting Claude caps, but may be too much for very nontechnical users. He also notes the repo was very young, which is an important maturity caveat.

1. Create a safe pilot environment

Use a throwaway workspace or container. Do not start with a client repo.

mkdir -p ~/ai-design-pilots
cd ~/ai-design-pilots
git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable
corepack pnpm --version
pnpm install
pnpm tools-dev run web

If the daemon fails, check logs before changing versions:

pnpm tools-dev check
pnpm tools-dev logs
node -v

2. Run a controlled design task

Prompt shape:

Create a high-fidelity SaaS analytics dashboard for founder/executive users.
Audience: startup operators.
Tone: dense, calm, dark, utility-first.
References: Datadog data density, Linear spacing, Stripe clarity, Bloomberg information hierarchy.
Scope: one overview page with 2–3 tab states.
Required sections: MRR, active workspaces, retention cohort, world heat map, live event stream.
Avoid: purple gradient fog, decorative blobs, fake lorem ipsum.
Evaluation: responsive layout, accessible contrast, clean HTML/CSS, no external trackers.

3. Save artifacts and screenshots after every model pass

Create a small evaluation folder:

prototype-eval/
  01-claude-first-pass/
  02-codex-live-stream-edit/
  03-openrouter-low-cost-variant/
  review.md

In review.md, track model, prompt, elapsed time, visible regressions, cost/credit use, and final decision.

4. Run production gates before client use

Checklist:

  • License notices retained for Open Design and any bundled third-party assets.
  • No client secrets or private data in .od, logs, screenshots, or generated code.
  • Output does not copy a named brand’s protected look/trade dress too closely.
  • HTML/CSS reviewed by a human or code-review model.
  • Accessibility basics checked: contrast, keyboard navigation, semantic structure, alt text.
  • Responsive breakpoints tested.
  • Dependencies audited.
  • Deployment target reviewed for environment variables and public exposure.

Comment insights

The comments are unusually useful because they expose real deployment and expectation issues.

  • Limits pain is real. Several viewers say Claude limits max out in half a day or a few hours. This supports the creator’s motivation, even if exact Claude Design usage limits vary by plan and feature.
  • Setup friction exists. The top comment gives a concrete “Daemon is offline” workaround involving Node 22 portable and pnpm tools-dev run web. This conflicts with current Open Design docs requiring Node 24, so treat it as a troubleshooting clue, not canonical setup guidance.
  • Security concerns are present. A viewer asks how to vet downloaded repos. This is the right concern for any local agentic tool that can spawn processes, store keys, and read files.
  • Quality is contested. One commenter says Open Design does not replace Claude Design because outputs were less refined even with Codex 5.5 or Claude Opus. Jack partly agrees, saying Claude remains best for frontend design and maybe Claude Design has a different underlying model/prompt setup. This is important contradicting evidence against “replaced Claude Design.”
  • Claude credits can still burn quickly. Another commenter says Open Design burns through Claude Code credits. Jack replies that you can switch models, which is true, but switching models is not the same as unlimited Claude usage.
  • Model-switching value is the real answer to “unlimited?” A viewer asks whether a $20 Claude plan becomes unlimited inside Open Design. The accurate answer is no: Open Design lets you bring multiple paid/free routes into one workflow; it does not expand Claude’s subscription limits.
  • Adjacent tools mentioned: Glaido for voice dictation, HyperFrames for motion graphics, OpenRouter, OpenCode, Antigravity, Vercel, WordPress/custom backends, DeepSeek API, Gemini Pro.

Deep research: claims, evidence, and contradictions

Verdict

Open Design is worth piloting as a local-first, open-source design-agent workspace, especially if you already use Claude Code, Codex, Gemini CLI, OpenCode, or similar agents. The practical verdict is mixed-positive: use it for controllable artifact generation and model routing, but do not take “100% local,” “unlimited,” or “free” literally unless your selected model/media/deploy path is also local and your usage limits/costs are known.

Claim 1: Open Design is an open-source Claude Design alternative

Supporting evidence: The official GitHub repo nexu-io/open-design describes itself as “the open-source alternative to Claude Design,” local-first, BYOK, and driven by coding-agent CLIs and design systems. GitHub API metadata checked during this analysis showed Apache-2.0 licensing, creation on 2026-04-28, active pushes on 2026-05-20, and tens of thousands of stars. The README names capabilities including skills, brand-grade design systems, sandboxed preview, imports, exports, and multiple agent CLIs.

Contradicting/cautionary evidence: Anthropic’s own Claude Design support docs describe a managed product with chat + canvas, organization design systems, inline comments, sharing, export, and Claude Code handoff. Open Design can approximate the artifact loop, but it is not the same product, not backed by Anthropic’s hosted design system workflow, and may not match Claude Design’s quality or collaboration features.

Verdict: Agree, with scope limits. High confidence. It is a real open-source alternative, especially for technical users, but “alternative” should not be read as feature-equivalent replacement.

Claim 2: Open Design is “100% local”

Supporting evidence: Open Design’s architecture is local-first: local daemon, local project folders, local preview, SQLite persistence under .od, and local CLI spawning. The README and QUICKSTART emphasize running the product locally with pnpm tools-dev or Docker.

Contradicting evidence: The same README and quickstart describe BYOK API proxy modes for Anthropic/OpenAI/Azure/Google/Ollama Cloud/SenseAudio and model CLIs such as Claude Code, Codex, Gemini, OpenCode, Cursor, Copilot, etc. The video itself uses Claude Code/Codex-style hosted model routes, OpenAI image generation, OpenRouter, and Vercel deployment. Those are not purely local.

Verdict: Disagree with the literal claim; agree with “local-first.” High confidence. The app/runtime can be local, but the selected model, media generator, or deployment path may be cloud-based.

Claim 3: Open Design enables “unlimited/free” design work

Supporting evidence: Open Design lets users switch away from Claude Design/Claude Code limits to other models and providers, including free or low-cost OpenRouter variants and local models where available. That can increase throughput and reduce dependency on one subscription cap.

Contradicting evidence: OpenRouter’s FAQ says it uses credits, charges per model/provider, and :free models have low rate limits. It specifically states free model rate limits depend on purchased credits, with higher free limits for users who have purchased at least $10 in credits and lower limits otherwise. Claude Code docs explain token/cost tracking and recommend managing model choice, context, and usage; Open Design does not remove those costs. Comments also report Claude Code credit burn.

Verdict: Disagree as stated. High confidence. Open Design can be cheaper and more flexible, but not unlimited. “Free” means “some free routes exist with limits,” not “infinite production-grade usage.”

Claim 4: Apache-2.0 makes it safe for commercial/client work

Supporting evidence: Open Design’s repo license is Apache-2.0. The Apache license grants broad copyright and patent rights, including use, modification, distribution, sublicensing, and sale, with obligations around license copies, notices, modified-file notices, and NOTICE files.

Contradicting/cautionary evidence: Apache-2.0 covers the licensed software, not necessarily third-party brand names, trademarks, trade dress, uploaded client assets, generated images, or model-provider terms. Open Design’s core feature—using named brand design systems—raises separate commercial/IP review issues if outputs closely imitate recognizable brands.

Verdict: Mixed. High confidence. Apache-2.0 is commercially friendly for the tool, but “safe for clients” is too broad. Use it commercially with notice/license compliance and separate IP/data review.

Claim 5: Open Design output quality can replace Claude Design

Supporting evidence: The video demo shows a polished interactive analytics dashboard, model switching, export paths, and image integration. Open Design’s structured discovery forms and brand systems are plausible quality boosters.

Contradicting evidence: A commenter reports that designs were not as refined or finished as Claude Design, even using Codex 5.5 and Claude Opus through Open Design. Jack’s reply partly concedes that Claude remains best for frontend design and speculates Claude Design may have a different underlying model/prompt system. Anthropic/third-party Claude Design docs emphasize organization design systems, inline comments, and managed canvas workflows that Open Design may not fully match.

Verdict: Mixed. Medium confidence. Open Design can replace Claude Design for technical users who value local files, model routing, and export control. It may not replace Claude Design for nontechnical users, team collaboration, or highest-polish first-pass output.

Claim 6: OpenRouter/OpenCode lets you use “any model”

Supporting evidence: OpenRouter documents a unified API for hundreds of models, pricing metadata, model variants, and routing/fallbacks. OpenCode’s official README describes it as an open-source AI coding agent with broad installation options. Open Design supports multiple coding-agent CLIs and BYOK proxy modes.

Contradicting evidence: “Any model” is bounded by provider support, account access, API keys, rate limits, model capabilities, tool-calling support, context windows, pricing, and each tool’s adapter quality. Some models are poor at frontend design or cannot reliably edit generated artifacts.

Verdict: Agree in practical spirit, not literally. High confidence. The model surface is broad, but production routing requires capability and cost testing.

Claim 7: Antigravity is a useful environment for this workflow

Supporting evidence: Google’s Antigravity announcement describes an agentic development platform with an editor view and manager surface for spawning agents that plan, execute, and verify work across editor, terminal, and browser. That maps well to the creator’s “ask Antigravity to clone/open the repo” workflow.

Contradicting/cautionary evidence: Antigravity itself is another agentic layer with its own permissions, model routes, rate limits, and preview maturity. Using Antigravity to run Open Design adds orchestration power but also another security/data-flow surface.

Verdict: Agree for technical users. Medium-high confidence. It is a sensible operator shell for installing/running agentic design tools, but it should not bypass normal repo vetting.

Screen-level insights tied to frames and transcript

  • 0:00 — Design title card. The frame shows a simple “Design” graphic while the transcript introduces the “Claude Design replacement” premise. It anchors the video around artifact generation rather than ordinary chat.
  • 1:00 — Value-proposition slide. The screen compares Claude Design as a closed/paid product versus Open Design as an open workshop where the user owns the runtime. It visually reinforces the local/open narrative, but the later model/API choices complicate that claim.
  • 2:02 — Open Design landing page / feature cards. The visible page says “Meet Open Design,” highlights Apache-2.0, auto-detected CLIs, 71 brand systems, and local-first positioning. This is the strongest screen evidence for the repo’s stated feature set.
  • 2:33 — Brand system grid. The frame shows cards for Apple, Vercel, Stripe, Notion, Tesla, Figma, Airbnb and copy about inheriting voice, typography, palette, and layout language. Technical takeaway: Open Design is using structured design-system prompts/files, not just a generic “make it like Stripe” instruction.
  • 3:04 — License/commercial feature card. The highlighted card says Apache-2.0 is “safe for clients,” with tags like client work/no watermark/resell. This is where the video’s legal claim appears visually; it is directionally supported by Apache-2.0 but overbroad without trademark/IP caveats.
  • 5:04 — Setup modal. The Open Design setup screen shows execution mode tabs, Local CLI vs Anthropic API, and agent choices including Claude Code, Gemini CLI, Hermes, Cursor Agent, GitHub Copilot CLI, and Qwen Code. This is key evidence that the product is a router/orchestrator around existing agents.
  • 5:35 — New prototype dashboard. The OpenUI/Open Design screen shows project name, design system, wireframe/high-fidelity frame choice, create button, and “Import Claude Design ZIP.” Workflow: start a project with explicit fidelity and optional Claude Design migration.
  • 6:36 — Direction picker. The assistant “Claudy” asks the user to “Pick a dark direction” with palette choices. This supports the transcript’s point that Open Design asks structured questions before generating, improving controllability.
  • 7:39 — Generated dashboard. The frame shows a dense “Halo Console” dashboard with charts, world map, retention heatmap, and live event stream. It demonstrates the result of the prompt and why the creator sees value: one-shot high-fidelity HTML-style prototype with enough structure to iterate.

My read / why it matters

Open Design matters because it turns “AI design” from a closed hosted canvas into a reproducible local/dev workflow. For builders, agencies, and technical product teams, that is powerful: you can version artifacts, route models, inspect generated code, import/export HTML, and connect the output to real engineering systems.

But the right framing is not “Claude Design is dead” or “unlimited free local design.” The right framing is:

Open Design is a promising local-first orchestration layer for AI-generated design artifacts. It is best used by technical operators who can manage model routes, vet repos, review code, and apply legal/privacy judgment.

If you are a designer or PM who wants a polished managed canvas with team sharing and organization design-system setup, Claude Design may still be smoother. If you are an engineer/agency operator who wants files, CLIs, model optionality, export control, and cheaper iteration, Open Design is absolutely worth piloting.

Verification notes

  • Source artifacts checked: transcript/comment extraction from /root/.openclaw/workspace/youtube-extract/ju-T6uQNPSg/ju-T6uQNPSg-extraction.md, structured extraction from ju-T6uQNPSg-extraction.json, frame metadata from ju-T6uQNPSg-frames.json, and image analysis of the extracted key frames.
  • External sources checked: Open Design GitHub repo metadata, README, LICENSE, and QUICKSTART; Apache License 2.0 text; OpenRouter FAQ/models documentation; OpenCode GitHub README/LICENSE; Anthropic Claude Design support pages; Anthropic Claude Code docs for costs/model configuration/third-party integrations; Google Antigravity announcement; DataCamp’s Claude Design explainer as a secondary overview.
  • Actionable Insights audit: Top section was checked for concrete first steps, links, commands, evaluation criteria, cautions, and direct tie-back to transcript/comment/research evidence. Weak headline claims were converted into operational checklists rather than repeated as facts.
  • Evidence audit: Major claims were separated into supporting and contradicting evidence with explicit verdicts. The strongest unresolved uncertainty is real-world output quality versus Claude Design because the available evidence is demo-based plus anecdotal comment pushback, not a controlled benchmark.
  • Remaining uncertainty: Open Design is moving quickly; README counts for skills/design systems/agents may change. Node compatibility evidence conflicts between the current QUICKSTART and a user comment, so users should follow current repo docs first and treat the comment workaround as situational. Legal/commercial notes are practical risk analysis, not legal advice.