Public launch scope completion

Problem

The profiling pipeline has been validated internally but is not ready for public use. Production-safety concerns remain unaddressed: there are no query cost guardrails to prevent runaway warehouse spend on very large tables, no graceful degradation when profiling is interrupted mid-run, and no clear rollback procedure if a profiler update produces incorrect semantic types across users' cached inspect.json files. The gap between "works for internal teams who can ask engineering for help" and "safe for external users running unsupervised against their production warehouses" must be closed before launch, with explicit scope boundaries defining what is and isn't supported in the initial public release.

Context

• The backlog for warehouse profiling, semantic inference, and analyst-facing inspect/context artifacts is broader than what public launch can safely absorb, so this task has to separate launch-critical scope from attractive but deferrable work.
• A credible launch needs stable default behavior, explicit unsupported cases, and a rollback story for the riskiest surfaces rather than a promise to finish everything.
• Expected touchpoints include dataface/core/inspect/, schema-context consumers, inspect docs, and core tests, launch checklists, and any tasks or docs that currently blur the line between required launch scope and post-launch follow-up.

Possible Solutions

• A - Keep the full backlog in scope until the last minute: preserves ambition, but guarantees launch risk remains unclear.
• B - Recommended: define a minimum externally supportable launch scope and close only those blockers: make explicit deferrals, owner assignments, and rollback expectations.
• C - Shrink scope aggressively to the point of a weak launch: lowers risk, but may undercut the product story and user value.

Plan

1. Audit the open work for warehouse profiling, semantic inference, and analyst-facing inspect/context artifacts and classify each item as launch-critical, launch-adjacent, or post-launch follow-up.
2. Document the required launch behaviors, known unsupported cases, and any rollback or kill-switch expectations for high-risk areas.
3. Close or explicitly defer the remaining blockers, linking each deferral to a tracked follow-up with clear risk notes.
4. Reconcile the launch scope with docs, QA/review evidence, and operator expectations so launch readiness is credible and explainable.

Implementation Progress

Review Feedback

• [ ] Review cleared