Service call scope
Define caller and callee first so rules stay tied to actual call paths.
PRODUCT EXPERIENCEProduct experience is coming soon.
The public Lattice.Hub Console experience environment is being prepared.
SERVICE GOVERNANCE
Nine rule types,one deterministic release model.
Routing, lanes, rate limiting, circuit breaking, fault detection, lossless up/down, call authorization, traffic mirroring, and traffic Mock share one chain: rule → versioned release → active view.
01 / SCOPE BEFORE POLICY
Answer “who it applies to” before “what it does.”
Governance detail keeps service call scope, rule content, and history in one workspace—so policy review returns to a real call relationship instead of abstract parameter checks.
Rules and sub-rules
View match conditions, actions, and governance parameters in one policy context.
Version and release history
Track how rules move from edit content to runtime versions, with recovery entry points.
Console · Governance Rule DetailReal product UI: caller, callee, rule granularity, and sub-rules.
02 / NINE DOMAINS
Governance capability is not a scatter of toggles.
Nine rule types use consistent page language for scope, content, version, and release state. The three groups below are site information architecture—not extra storage tiers.
Routing
Select target versions by labels, weights, and request conditions.
Lane
Keep a set of related services closed on one environment identifier.
Traffic mirroring
Copy requests to shadow services without changing the primary path result.
Rate limiting
Constrain traffic entry by request dimensions and quotas.
Circuit breaking
Isolate unhealthy calls after anomaly thresholds trigger.
Fault detection
Identify unhealthy instances with active and passive signals.
Lossless up/down
Protect in-flight requests during instance lifecycle changes.
Call authorization
Enforce access policy by service identity and request conditions.
Traffic Mock
Return controlled responses by rule for integration and drills.
03 / TWO VIEWS
Rules being edited and versions in runtime are not the same thing.
Revision marks content change in the management view; release version marks one deterministic runtime delivery. Both matter—they must not collapse into one “saved” state.
Management view
For create, modify, and review—shows current rule content, Revision, and pending release changes.
Release view
For runtime consumption—shows immutable versions in their corresponding release states.
04 / RELEASE LIFECYCLE
Save is not active; release is the boundary.
The release chain turns human judgment into deterministic runtime versions and keeps clear records for canary, full rollout, and recovery.
Edit
Adjust rule content and save edit state—this step does not change the runtime view.
Release
Promote confirmed content to a release version with explicit canary or full scope.
Active
Only release versions in active state enter the runtime consumption path.
Recover
Return to a known version through release history instead of reconstructing past rule state.
05 / RUNTIME LANDING
One release model, many runtime shapes.
The control plane delivers deterministic governance views; each runtime consumes and enforces within its supported scope—we do not equate protocol compatibility with full capability parity.
Rust SDK
Proxyless: consume supported governance views in-process against the control plane.
Thin SDK
Multi-language contract cores (Go / Java / Python / Node.js / C++ / C#) that join the local Pole Sidecar via Sidecar Session.
Pole Sidecar
Consume governance views within current component support, with extension points for more policies.
Proxy Mesh / Gateway
Consume published rules in mesh or gateway data planes.
Protocol clients
Gain corresponding capability through compatible protocols without promising all nine rule types on every runtime.
MAKE RELEASE EXPLICIT