Three ways to give the policy engine the metadata it needs.
Policies decide against resource metadata like classification and sensitivity. Gateco resolves it via a configurable hierarchy: sidecar, inline, or SQL view.
Metadata resolution mode is set per connector. Sidecar is the default and works everywhere.
The three modes
Sidecar, the default, keeps policy metadata on Gateco's own resource records. It is always available after a resource is registered and asks nothing special of the vector store, which is why most teams start here. Inline reads metadata directly from the vector payload, for stores where each chunk already carries its own classification and labels. SQL view reads from a structured database view, available for the Postgres family, using validated table and column identifiers and never raw SQL.
Auto mode tries them in order, inline, then SQL view, then sidecar, and uses the first that resolves. Every retrieval audit record notes which mode actually resolved the metadata, so the resolution path is observable.
Resolution mode and readiness
The mode you choose affects how granular your enforcement can be. Sidecar metadata lives on the resource record, which supports resource-level policy (readiness level L3). Inline and SQL view can carry per-chunk metadata, which is what enables chunk-level policy (readiness level L4). Pick sidecar for simplicity, and move to inline or SQL view when you need each chunk to carry its own access metadata.
Inline mode requires a metadata field mapping so Gateco knows which payload fields hold the policy metadata; without it, inline retrieval fails closed rather than guessing. That safe-default behavior holds across the whole resolution hierarchy.
Frequently asked questions
Which mode should I start with?
Sidecar. It is the default, it works with every connector, and it requires no changes to how your vectors are stored. Move to inline or SQL view only when you need per-chunk metadata for chunk-level policy.
Is the SQL view mode safe against injection?
Yes. SQL view mode uses structured configuration with validated table and column identifiers. It never accepts or executes raw SQL strings from configuration.
Can I tell which mode resolved a given retrieval?
Yes. The audit record for each retrieval includes the metadata resolution mode that was actually used, which is useful when debugging an auto-mode connector.