diff --git a/kubecon-prep/FAQ_OBSERVABILITY_OPERATORS.md b/kubecon-prep/FAQ_OBSERVABILITY_OPERATORS.md
new file mode 100644
index 0000000..c54b904
--- /dev/null
+++ b/kubecon-prep/FAQ_OBSERVABILITY_OPERATORS.md
@@ -0,0 +1,236 @@
+# FAQ: Headlamp Plugins for Kubernetes Operators
+
+**Context**: For operators who are thinking about observability, visibility, and management during/after KubeCon. Answer real questions with real context, not marketing language.
+
+---
+
+## Observability & Visibility
+
+### Q: I have a Prometheus stack already. Why do I need Headlamp plugins?
+
+A: You probably don't need them. Prometheus is good at what it does: metrics. But Prometheus is not a dashboard. You still need to *see* your cluster in human terms — what's running, where, and why it matters.
+
+Headlamp plugins show you the cluster state in the UI. Your Prometheus metrics live somewhere else. They're complementary, not competitive.
+
+If you're happy with kubectl and Prometheus graphs, keep going. If you find yourself switching between tools, Headlamp might fit.
+
+---
+
+### Q: Is this "observability"? I thought we needed traces, metrics, logs...
+
+A: You're thinking of the marketing definition. In practice, operators need:
+1. To see what's running (cluster state)
+2. To understand if it's healthy (metrics)
+3. To know what went wrong (logs, events)
+
+Headlamp handles #1. Your existing stack handles #2 and #3. The magic is in integrating them, not replacing them.
+
+Our plugins sit in the UI where you're already looking. That's the whole point.
+
+---
+
+## Individual Plugins
+
+### Q: When should I use the Rook plugin?
+
+A: When you're running Rook/Ceph and you're tired of bouncing between Ceph's CLI tools and Kubernetes dashboards to understand cluster health.
+
+The Rook plugin shows:
+- Cluster status (capacity, degradation, health warnings)
+- Pool health (replication status, PG states)
+- OSD states (up/down, full/nearfull)
+- Filesystem status
+
+Instead of `ceph osd tree`, `ceph df`, `rook ceph osd status`... you look at one place.
+
+**Not for**: Teams that want deep Ceph debugging. For that, you still need Ceph's native tools.
+
+---
+
+### Q: What's the GPU plugin actually for?
+
+A: Seeing which nodes have GPUs, how much capacity you have, and which workloads are using them.
+
+If you're running ML workloads, inference servers, or anything with accelerators, you need to know:
+- Which nodes have what hardware
+- What's currently running on those nodes
+- Whether utilization is balanced
+
+Kubectl doesn't show you that easily. Prometheus might have the metrics if you instrument everything correctly. The GPU plugin shows it at a glance.
+
+**Not for**: Teams not using GPUs. This is a specialized tool.
+
+---
+
+### Q: Why a sealed-secrets plugin? Isn't that a security risk — showing secrets in a UI?
+
+A: The plugin doesn't show the secret *values*. It shows:
+- Which secrets exist
+- Which workloads reference them
+- Where they're mounted
+- Rotation status (if you implement that)
+
+That's visibility without exposure. It answers "what secrets are in my cluster?" not "what are the passwords?"
+
+Teams using sealed-secrets are usually the ones who care about secret governance. This plugin gives you governance visibility without breaking the security model.
+
+---
+
+### Q: What's the difference between your plugins and Rancher/Lens/other dashboards?
+
+A: They're trying to be the entire dashboard. We're building plugins for the gaps.
+
+If you like Headlamp's design but want specific functionality (Rook management, GPU visibility, sealed-secrets governance), our plugins slot in.
+
+If you prefer Rancher's philosophy, great. Use Rancher. Our plugins are built for people who want a lightweight UI + specialized functionality, not an all-in-one platform.
+
+---
+
+## Operational Questions
+
+### Q: Do I need to run Headlamp to use these plugins?
+
+A: Yes. Our plugins extend Headlamp. Headlamp is lightweight (single container), but you need to be running it.
+
+If you're not using Headlamp, these plugins don't help. If you are, they extend what you can see.
+
+---
+
+### Q: How do you handle RBAC? Can my developers see things they shouldn't?
+
+A: Headlamp respects your cluster's RBAC. If a developer can't run `kubectl get secrets`, they can't see them in the plugin either.
+
+Your security boundaries are your security boundaries. Our tools don't bypass them.
+
+---
+
+### Q: What's the upgrade path? Will my existing configuration break?
+
+A: We try not to break things. Honest answer: we're still young. Check release notes before upgrading. If you find a breaking change, file an issue and we'll help.
+
+If you need stability guarantees, we're not there yet. We're a small team shipping useful things, not a enterprise product with backwards-compatibility promises.
+
+---
+
+### Q: Can I run Headlamp + plugins in an air-gapped environment?
+
+A: Yes. If you can run Headlamp, you can run the plugins. No external dependencies, no phone-home telemetry.
+
+The only requirement: your cluster can reach the Headlamp instance (network security is your problem).
+
+---
+
+## Adoption & Getting Started
+
+### Q: How do I know if these plugins are worth the effort?
+
+A: Try one. Pick the one that solves a problem you're actually having.
+
+Rook users: Use the Rook plugin for a week. See if it saves time. If not, delete it.
+GPU users: Use the GPU plugin. See if you'd miss it.
+Sealed-secrets users: Use the plugin for secret governance.
+
+Don't add plugins "just in case." Add them when they're solving a real problem.
+
+---
+
+### Q: What's the support story? If something breaks, what happens?
+
+A: GitHub issues. We're responsive (usually within 24-48 hours). If it's a security issue, email the maintainers directly (see repo).
+
+We're not a SaaS with SLAs. We're open source with humans behind it who care. That's the tradeoff.
+
+---
+
+### Q: Where do I submit feature requests?
+
+A: GitHub issues with the `feature-request` label. Be specific. "Make it faster" doesn't help. "Show OSD versions in the Rook plugin" does.
+
+---
+
+## Technical Depth
+
+### Q: How much overhead do these plugins add?
+
+A: Minimal. Plugins are JavaScript that runs in your browser. They query your cluster API, same as kubectl does.
+
+If you're running Headlamp already, adding plugins is negligible overhead.
+
+---
+
+### Q: Can I modify the plugins for my own use?
+
+A: Yes. All plugins are Apache-2.0 licensed. Fork, modify, deploy. We appreciate improvements back in PRs, but no obligation.
+
+---
+
+### Q: Do these plugins work with managed Kubernetes (EKS, GKE, AKS)?
+
+A: If Headlamp works with your platform, the plugins work. Headlamp just needs API access.
+
+We develop against standard Kubernetes. If you hit a managed-service-specific issue, let us know.
+
+---
+
+## When to Say No
+
+### Q: Should I use these in production?
+
+A: Depends on what you mean by "production." If you mean "will it crash my cluster," no. Headlamp + plugins are read-only.
+
+If you mean "is this enterprise-grade," probably not yet. We're under 1 year old. We're useful, not bulletproof.
+
+Try it. Monitor it. Have a fallback (you do have kubectl, right?). If it fails, switch back.
+
+---
+
+### Q: Can these plugins replace my existing monitoring stack?
+
+A: No. Don't try. This is visibility, not comprehensive monitoring.
+
+You still need logs, metrics, traces, alerting. We're the UI layer for cluster state + specialized views.
+
+---
+
+## Getting Help
+
+### Q: I found a bug. What do I do?
+
+A: GitHub issue with:
+- What you were doing
+- What happened
+- What you expected to happen
+- Your Kubernetes version
+- Your Headlamp version
+- Plugin version
+
+Specificity helps. "It doesn't work" doesn't. "When I click the Rook tab, I get a 403 error" does.
+
+---
+
+### Q: I want to contribute. Where do I start?
+
+A: GitHub issues with `good first issue` label. Read the CONTRIBUTING.md in each repo. Start small.
+
+We're a small team. contributions that improve things make a real difference.
+
+---
+
+## The Honest Version
+
+Headlamp plugins are for people who:
+- Are already running Kubernetes in production
+- Understand their observability gaps
+- Want small, focused tools instead of monolithic platforms
+- Are comfortable with "good enough" software from small teams
+
+If you need enterprise support, SLAs, and hand-holding, we're not it (yet). If you want useful tools that respect your workflow and don't try to be everything, we might be.
+
+Try us. If we don't fit, no hard feelings. There are plenty of other dashboards. Find the one that works for your team.
+
+---
+
+**Last updated**: March 13, 2026
+**Audience**: Kubernetes operators, platform engineers, storage admins
+**Tone**: Honest, not salesy, specific, realistic about limitations
+
diff --git a/kubecon-prep/KUBECON_RESPONSE_TEMPLATES.md b/kubecon-prep/KUBECON_RESPONSE_TEMPLATES.md
new file mode 100644
index 0000000..b8e6c4f
--- /dev/null
+++ b/kubecon-prep/KUBECON_RESPONSE_TEMPLATES.md
@@ -0,0 +1,176 @@
+# KubeCon EU 2026 — Response & Tactical Post Templates
+
+**Status**: Ready-to-deploy. Update dates/times as conference progresses. Use if conversations align with these narratives.
+
+---
+
+## Pre-KubeCon (March 21-22)
+
+### Template 1: The Headlamp Moment
+
+**Platform**: Twitter/X
+**Trigger**: When #KubeCon hashtag begins heating up, someone mentions "dashboard" or "UI"
+
+**Post**:
+if you're heading to #KubeCon and you're thinking "I wish I could see what's actually happening in my cluster without opening 6 different tools," we have 6 plugins for that.
+
+see you in Amsterdam.
+
+**CMO Note**: Soft sell. Positions us as understaters. Uses first-person ("we have") rather than "check out." Timing: Friday-Saturday before conference opens.
+
+---
+
+### Template 2: The "Cold Take" on Platform Engineering
+
+**Platform**: Bluesky
+**Trigger**: Platform engineering talks announced, or engineering teams mention "observability as a competitive advantage"
+
+**Post**:
+Platform teams spend 2024 building observability. They spent 2025 fighting with it. KubeCon 2026 is about finally making it *work*.
+
+(Hint: Headlamp makes the "finally" part easier.)
+
+**CMO Note**: Positions us as people who understand the maturity curve. Not condescending. Acknowledges that good observability is *work* not just tooling. Implies we've thought about this problem space.
+
+---
+
+## Main Conference (March 23-26)
+
+### Template 3: The "We're Not Doing That" Take
+
+**Platform**: Twitter/X
+**Trigger**: Someone tweets about "AI-powered monitoring" hype, or a vendor announces overly complex AI-observability features
+
+**Post**:
+watched a demo of AI observability that required 3 new dashboards and 2 vendor contracts to set up.
+
+the goal of observability is seeing what's wrong. if your tool gets in the way of that, it's not observability.
+
+(we kept ours simple.)
+
+**CMO Note**: Leans into Headlamp's philosophy (small, focused plugins) vs. sprawling observability stacks. Not attacking anyone. Just stating our bias. Safe because we actually *do* keep our approach simple.
+
+---
+
+### Template 4: Real-Time Response to "How Do You Monitor [X]"
+
+**Platform**: Twitter/X (Thread)
+**Trigger**: Someone asks "how do you monitor GPU usage" or "how do you track CSI performance"
+
+**Thread Option A** (GPU):
+Q: How do you monitor GPU usage in Kubernetes?
+
+Short answer: You look at actual metrics. Not dashboards about dashboards. Not vendor abstractions. You look at what your hardware is actually doing.
+
+Headlamp + intel-gpu plugin. See your GPU. No middleman. [link to docs]
+
+**Thread Option B** (Storage):
+Q: How do you track Rook/Ceph performance?
+
+Real answer: Stop thinking about monitoring as a separate system. Rook is part of your cluster. You need visibility into it from the same place you look at everything else.
+
+That's the whole reason we built the Rook plugin. [link to docs]
+
+**CMO Note**: These are hyperspecific. Only deploy if question arises. Shows expertise without being pushy. Links to actual docs (once we have them on GH pages).
+
+---
+
+### Template 5: The "We Attend Quietly" Take
+
+**Platform**: Mastodon
+**Trigger**: General KubeCon reflection mid-conference (March 24-25)
+
+**Post**:
+KubeCon observation: Nobody is pretending their observability stack is simple anymore. Everyone admits it's complex. The conversation has shifted from "we have visibility" to "how do we make visibility manageable."
+
+We have a thesis on that. (It involves not adding more layers.)
+
+**CMO Note**: Intellectual positioning. Suggests we have *design philosophy* not just tools. Mastodon audience appreciates meta-commentary about industry trends. Doesn't mention product directly until the last line.
+
+---
+
+## If External Events (March 21-27)
+
+### Template 6: Security/Supply Chain Angle
+
+**Trigger**: If a security incident, CVE, or supply chain story breaks during conference
+
+**Platform**: Twitter/X
+**Post**:
+[Current incident] is why we built sealed-secrets plugin.
+
+Not because we think we're special. Because operators shouldn't have to choose between "use secrets" and "know where they're being stored."
+
+If you're at #KubeCon, stop by and we can talk about it. [link]
+
+**CMO Note**: Shows we're paying attention. Ties conference energy to our actual products. Empathetic (don't position as saviors, just problem-solvers). Only use if an actual security story breaks.
+
+---
+
+### Template 7: Cost Angle
+
+**Trigger**: If cost/efficiency is a hot KubeCon keynote theme, or someone discusses "cost-aware monitoring"
+
+**Platform**: LinkedIn
+**Post**:
+KubeCon theme observation: "Cost-aware observability" is trending because teams are finally admitting that monitoring infrastructure is expensive.
+
+The plugin approach (small, focused, optional) is inherently cost-aware. You don't pay for observability you don't use.
+
+This is intentional design.
+
+**CMO Note**: Positions Headlamp's modular philosophy as a *feature*. Not "we're cheaper" but "we're more efficient by design." Works if cost is a main theme.
+
+---
+
+## Post-KubeCon (March 27+)
+
+### Template 8: The Recap
+
+**Platform**: Twitter/X
+**Trigger**: March 27-28, after conference ends
+
+**Post**:
+KubeCon takeaway: The best tools are the ones your team forgets they're using because they just work.
+
+We built Headlamp plugins like that. Small. Focused. Invisible until you need them.
+
+Did we miss you in Amsterdam? [link to plugin docs]
+
+**CMO Note**: Humble, unsalesy. Doesn't claim we nailed it, just states our design goal. Bridges back to self-directed learning/documentation (not aggressive marketing).
+
+---
+
+## General Guidelines for Day-Of Responses
+
+1. **Monitor, don't dominate**: Respond to conversations, don't start them.
+2. **Listen for pain, not keywords**: "I can't see X" beats "person mentioned dashboard."
+3. **Be helpful first**: Answer questions. Mention our stuff only if relevant.
+4. **Keep it real**: If someone asks a question we don't have a good answer for, say so.
+5. **Timing**: Responses should go out within 2-4 hours of trigger, not instant (not trying too hard).
+6. **Tone check**: Every response should pass the "would an actual operator write this" test.
+
+---
+
+## Tools & Hashtags
+
+**Primary hashtag**: #KubeCon (volume 24-26 March)
+**Secondary hashtags**: #KubeCon2026, #cloudnative, #kubernetes
+**Response hashtags**: #observability, #k8s, #platform-engineering (context-specific)
+
+**Monitoring tools** (if CMO provides access):
+- Twitter search: `#KubeCon`
+- Bluesky search: `KubeCon`
+- Reddit: r/kubernetes, r/devops, r/SRE (watch for questions)
+- Slack (if we're in cloud-native Slack): #kubecon-2026
+
+---
+
+## Notes
+
+- These are *optional* responses, not a mandate to post daily
+- Only deploy if you believe the response is valuable (not hitting publish for metric's sake)
+- If conference energy is low or our voice doesn't fit the conversation, that's fine
+- Post-KubeCon reflection is most important; day-of is engagement sugar
+- If something unexpected breaks (security issue, major outage), escalate to CMO before responding
+