Skip to main content
A VPoint (variation point) is a named seam around a function or method. You register it once at startup; every call then routes through the Varianz pipeline, where session-scoped stages can sample inputs and outputs or override the result. The model is the same in every language: register once, call many. Get a runtime handle, register your VPoints against it, then call the returned or instrumented function per request.
Three properties make VPoints safe to adopt incrementally:
  • Pass-through by default. With no stages attached (or with the SDK disabled), a VPoint runs the original function directly on a fast path. You can merge instrumentation before any registry exists.
  • You choose what to instrument. Varianz doesn’t require instrumenting all your code — annotate the functions that matter: payment charges, external calls, decision points you want to test around.
  • Session-scoped control. Stages attach per test session; traffic without a session ID never sees them.

​
Names

Every VPoint has a name. Give it explicitly, in scope/entity form:
Names are kebab-case segments separated by /. The first segment is a logical grouping (often the owning domain or service area); the last is the operation. Under the hood, names canonicalize to a four-part form (org/pkg/scope/entity) with the missing parts derived from your code’s package structure — tests can target a VPoint by any unambiguous suffix on / boundaries. See Naming and routing for the full rules.
Always name VPoints explicitly. Auto-derived names come from package and class names, which makes them fragile under refactoring.

​
Schemas

When a VPoint registers, the SDK derives a schema from the function’s parameter and return types — field names, types, and nested structures. The schema is what makes stages safe: CEL expressions are validated against it before they run, so a typo’d field name or a wrong type is caught at insert time, not in the middle of a test. Where the schema comes from differs by language: Prefer the static path (annotations, scanner, codegen) — lazily-resolved VPoints don’t exist in the registry until their first call, which means tests need a warmup request before stages can apply. See Build integration.

​
VPoints in each language

The registration idiom follows each language’s conventions — decorators in Python and TypeScript, a higher-order wrapper in Go, annotations in Java and Kotlin: For the step-by-step walkthrough, see Instrument a service.