Browser intelligence.
Azure authority.
One product, two very different jobs.

Local capability without local overreach

What I deliberately run in the browser.

The portfolio bundles a quantized MiniLM model, ONNX browser runtimes, deterministic WebAssembly cores, local semantic data, Workers, and production JavaScript. These assets let the browser retrieve, rank, compare, simulate, visualize, explain, and sometimes abstain without requiring an external language-model call for every interaction.

The rule is not “local is automatically safe.” Browser code still needs content security, asset integrity, bounded memory, safe DOM construction, capability checks, storage discipline, and explicit privacy behavior. The point is that local execution can be measured and governed as a first-class product path rather than treated as a novelty.

The public application still needs a durable authority plane

What ASP.NET Core and Azure retain.

The project targets net10.0. ASP.NET Core composes public routes, metadata, content services, databases, rate limits, forwarded-header handling, static-file delivery, health endpoints, and protected administration. Azure App Service provides the public hosting boundary and the deployment target.

That server side remains authoritative for responsibilities a browser cannot safely self-assert:

1. Public release identity.The application decides which compiled routes, views, manifests, and assets constitute the deployed product.
2. Shared persistence.Database-backed content and operational state are not accepted merely because one browser claims a write succeeded.
3. Server-side authorization.Protected administration, mutation endpoints, and shared data require independent checks outside client JavaScript.
4. Rate and resource policy.Server endpoints retain bounded admission rather than trusting a client to police its own request volume.
5. Canonical URLs and metadata.The host publishes the route, canonical identity, structured data, and crawler surface that search engines and external visitors actually receive.
6. Operational health.The process, database, Redis, and media boundaries can be checked separately instead of collapsing every dependency into one ambiguous green light.
7. Deployment and rollback.A new ZIP is not official until Azure serves the intended application and post-deployment checks confirm the real public result.

This is why OverLift separates proposal, execution, and accepted state. A browser can produce an excellent candidate. The server can return a successful HTTP response. Azure can report a completed deployment. The product still needs to verify which state is now public and whether required postconditions hold.

A small deployment surface is easier to understand and recover

The production path is intentionally boring.

The retained deployment script uses three visible stages:

dotnet publish -c Release
        ↓
ZIP the compiled publish directory
        ↓
az webapp deploy to Azure App Service
        ↓
verify the public application, routes, assets, and health

The script checks that dotnet, az, and zip exist, selects the intended Azure subscription, publishes without a platform-specific app host, creates a clean deployment ZIP, and sends that exact archive to the configured App Service. Source-only tests, historical evidence, local caches, and development settings are not supposed to leak into the publish boundary.

Simplicity matters. A deployment pipeline that performs hidden repairs, rewrites configuration, or silently substitutes an older package becomes difficult to reason about under pressure. The release artifact should be identifiable before upload, the public application should prove the same identity afterward, and rollback should point to a known prior artifact rather than a memory of what probably ran.

Build qualification and deployment remain separate on purpose. The owner command can run source, browser, security, packaging, and .NET compilation gates without mutating production. The deployment script does not claim those tests ran merely because Azure accepted a ZIP.

One green endpoint cannot explain a distributed product

Liveness, dependency readiness, and product correctness are different.

The application exposes a public process-liveness endpoint and separate database, Redis, and media health boundaries. That distinction prevents a slow or unavailable optional dependency from making the platform conclude that the process itself never started, while still preserving direct evidence about the dependency that needs attention.

A deployment can therefore be “accepted by the platform” and still fail a product smoke test. A process can be live while one database-backed route is unavailable. A page can return HTTP 200 while a required model or material asset returns 404. The correct response is not to redefine success. It is to keep each boundary explicit and let diagnosis point to the first broken contract.

The fast path must fail honestly

Common failure modes—and the authority they do not receive.

• Missing browser model: semantic reranking may fall back or abstain; it may not invent the model’s result.
• Missing GPU material: the renderer must report partial capability or fail qualification; it may not silently advertise full water and relief rendering.
• WebGPU device loss: a verified fallback may take over presentation, but it does not rewrite authoritative application state.
• Proxy or scheme mismatch: forwarded headers and canonical URL construction must preserve the real public origin rather than emitting insecure or duplicate identities.
• Database startup delay: public liveness stays narrow while database-backed paths remain explicitly unavailable.
• Successful ZIP deployment, bad route: production smoke tests reject the release even when the provider says deployment completed.
• Stale browser cache: release identity and asset versioning must expose the mismatch rather than letting an old script drive a new contract.
• Interrupted release: retained artifacts, hashes, logs, and rollback instructions must make recovery procedural rather than improvised.

The OverLift rule is consistent: acceleration, hosting, protocols, and providers can perform enormous amounts of useful work. None of them receives authority merely because it is fast, available, or confident.

This article is connected to executable source

The architecture is visible in the project.

The field article is grounded in the current portfolio implementation rather than a generic cloud diagram. The relevant proof surfaces include:

• seanfindley.csproj — the .NET 10 target, package boundary, and publish behavior.
• Program.cs — forwarded headers, rate limiting, response compression, static files, and separated health checks.
• deploy.sh — the explicit publish, ZIP, and Azure App Service deployment sequence.
• wwwroot/models/ and wwwroot/vendor/ — local MiniLM and ONNX browser runtime assets.
• NativePathfinderGlobe/, NativeMeaningVault/, and other native modules — deterministic WebAssembly authority and qualified presentation paths.
• TEST_PORTFOLIO_*.command and tools/ — source, browser, security, integrity, clean-extraction, and release qualification gates.
• wwwroot/sitemap.xml, canonical metadata, and structured data — the public discovery surface that must agree with route-backed content.

Those files do not prove every physical device, Azure condition, or future production incident. They prove the intended contract exists and can be tested. Owner-device compilation, live deployment, production smoke, real WebGPU behavior, and subjective visual acceptance remain named gates instead of being implied by a source audit.