Certain vs Optional: How Zunavi Decides What to Trust

A Feature Flag Registry That Makes a Promise

Most feature flag systems answer one question: is this feature on or off for this customer. Zunavi’s flag registry answers a second, more important question: can you trust what this feature tells you?

Every capability in the registry is tagged with a tier — certain or optional — and the tier isn’t cosmetic. It determines the default state, and it determines how the feature is allowed to talk about itself in the UI.

Certain: On by Default, Because It Has to Be

Five capabilities are marked certain and ship enabled by default: the core drawing ledger (drawing.core), metadata search (search.metadata), spec-to-drawing linking (spec.link), revision management and lineage (revision.management), and the approval workflow (approval.flow). These are the capabilities a drawing management system doesn’t get to be wrong about. If the ledger says a drawing is revision C, it has to be revision C. If the approval flow says a change was approved, that has to be true and traceable. There’s no “mostly right” version of a system of record.

Optional: Off by Default, Because Precision Isn’t There Yet

Seven capabilities are marked optional and ship disabled by default: titleblock OCR (scan.titleblock), 2D similarity search (similar.2d), 3D similarity search (similar.3d), cross-modal similarity search (similar.crossmodal), drawing comparison/diff (viewer.compare), the 3D viewer (viewer.3d), and the AI agent (ai.agent). These aren’t lesser features — they’re some of the most technically interesting parts of the platform. But they share a property the “certain” tier doesn’t: they’re assistive, they’re still maturing, and their output needs a human to verify it before it’s treated as fact.

Titleblock OCR reading a part number off a scanned drawing is genuinely useful — until it misreads a character and nobody catches it before that value propagates into a BOM. Vector-based similarity search surfacing a drawing that “looks like” an existing one is a great way to avoid a duplicate part number — unless someone treats the match as confirmed identity instead of a lead worth checking. The failure mode for optional features isn’t “it doesn’t work.” It’s “it’s right often enough that people stop double-checking it, right up until the one time it matters.”

Why Draw This Line at All

It would be simpler, from a marketing standpoint, to just call everything “AI-powered” and ship it all on. We think that’s the wrong call for engineering software specifically. Wrong data in a spreadsheet is annoying. Wrong data in a drawing ledger that a machine shop, a purchasing department, and a quality team all pull from can mean the wrong material gets ordered, the wrong revision gets machined, or a duplicate part number silently merges two different components. The cost of being wrong scales with how many downstream decisions depend on the data being right — and in manufacturing, that’s a lot of decisions.

So the tiering is a form of honesty by design: certain means “we stand behind this as fact,” optional means “this is a tool to help a person go faster, and the person is still the final check.” Even when an optional feature is turned on, the UI is required to label its output as assistive and needing verification — enabling the flag doesn’t upgrade the feature’s epistemic status.

The Rest of the Industry Is Wrestling With the Same Problem

We’re not the only ones who’ve concluded that AI-assisted features in engineering software need an explicit trust boundary. Commentary on AI adoption in PLM makes the same point from the vendor side: the goal isn’t to remove engineering judgment, but to reduce administrative work, surface relevant information, and flag potential issues — and AI “cannot be expected to resolve issues without disciplined governance and human validation” (Supply & Demand Chain Executive, on Aras’s approach to AI agents in PLM). Research on AI-assisted data labeling reaches a similar conclusion from a different angle: trust improves when a system shows its confidence rather than a bare answer, and users are (correctly) hesitant to trust outputs from models that behave as black boxes, with no visibility into what they were trained or tested on (arXiv, on AI-assisted data labeling interfaces). Zunavi’s certain/optional split and the “assistive, needs verification” UI language are our answer to the same problem those sources describe: showing confidence and provenance instead of asking users to take a match, an OCR read, or a similarity score on faith.

How the Flags Actually Resolve

Flags aren’t just a boolean per feature. Resolution happens in layers: the registry’s built-in default (defaultEnabled) is the base, a global database override can flip it for every tenant, and a tenant-specific override can flip it again for one customer. FeatureFlagsService.resolveAll(tenantKey) composes all three layers into a single resolved map per tenant, cached for 30 seconds so the check is cheap without being stale for long. Deployment mode plays into this too — Tenant.deployment can be ONPREM or CLOUD, and on-premise tenants get cloud-dependent flags turned off by default, since those often mean data leaving the building. (More on that in our on-premise-first architecture post.)

Enforced Twice, Not Suggested Once

The part that keeps this from being a UI-only convention is that it’s checked twice, independently. On the frontend, GET /api/v1/feature-flags returns the fully resolved map for the current tenant, and the UI uses it to decide what to render and which routes to expose. But a hidden button is not a security boundary — it’s a suggestion. So the same rule is enforced again on the backend: every route that depends on a gated capability is annotated with @RequireFeature(KEY), checked by a global FeatureFlagGuard registered as an APP_GUARD. If a request hits a disabled feature’s endpoint directly — flag off at the tenant level, feature not licensed, whatever the reason — the API returns a 403, full stop, regardless of what the frontend happened to render.

That double enforcement is the difference between a feature flag that’s a UI nicety and one that’s an actual guarantee. A tenant that has similarity search turned off doesn’t get to see stale cached results or hit an endpoint that “still kind of works” — the door is closed at the layer that actually matters.

Where This Fits Into the Bigger Picture

This tiering isn’t a launch gimmick tied to a release date — Zunavi doesn’t have one yet, and we’re not attaching one to this post either. It’s a structural decision baked into how the platform is built, meant to hold up whether a given optional feature graduates to certain next quarter or takes another year of tuning. The goal isn’t to ship fewer features; it’s to never let the UI claim more confidence than the underlying capability has actually earned.

---

Related reading: why we’re rebuilding Zunavi’s drawing ledger from scratch, why Zunavi is on-premise first, and the original introduction to Zunavi. Have opinions on where the certain/optional line should sit for your own workflow? We’d like to hear them — [email protected].