Oso Cloud rejects facts that dont match the

Not specified by the original author.

TL;DR

For tagging-style facts the policy does not use yet, add a declare statement with the allowed type signature before writing them.

Steps

1. When an Oso Cloud fact write is rejected, check the predicate against your policy: the argument count and types must match how the rule uses it, and the predicate name must be spelled exactly as in the policy. For tagging-style facts the policy does not use yet, add a declare statement with the allowed type signature before writing them.

When to use

You are seeing this: When an Oso Cloud fact write is rejected, check the predicate against your policy: the argument count and types must match how the rule uses it, and the predicate name must be spelled exactly as in the policy. Use this skill when you run into "Oso Cloud rejects facts that dont match the policy type signature".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (Facts as Data, Oso Cloud): documents a gotcha that trips agents writing facts. Facts stored as data must be unconditionally true with no if clauses, and Oso infers the expected argument types from how the predicate is used in policy rules. Mismatched types, missing arguments, and unrecognized predicates are all rejected. If you want to store a fact type the policy does not reference yet, you must declare its type signature with a declare statement first.

Verified resolution: When an Oso Cloud fact write is rejected, check the predicate against your policy: the argument count and types must match how the rule uses it, and the predicate name must be spelled exactly as in the policy. For tagging-style facts the policy does not use yet, add a declare statement with the allowed type signature before writing them.

Source URL: https://www.osohq.com/docs/reference/polar/facts-as-data

Not specified by the original author.

TL;DR

Oso Cloud centralizes facts for cross-service lookups, but the docs explicitly say to keep frequently-changing, high-cardinality data (like millions of files) and single-service data in the application DB instead.

Steps

1. Before pushing data into Oso Cloud, sort it: roles and global attributes go to Oso Cloud, high-cardinality or fast-changing data stays in your DB, and request-scoped values like the client IP or IDP token claims ride along as context facts that live only for the request. Syncing everything centrally buys you drift and sync jobs you did not need.

When to use

You are seeing this: Before pushing data into Oso Cloud, sort it: roles and global attributes go to Oso Cloud, high-cardinality or fast-changing data stays in your DB, and request-scoped values like the client IP or IDP token claims ride along as context facts that live only... Use this skill when you run into "Dont centralize high-cardinality facts in Oso Cloud".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (Overview of Facts, Oso Cloud): documents a gotcha that trips agents modeling authorization data. Oso Cloud centralizes facts for cross-service lookups, but the docs explicitly say to keep frequently-changing, high-cardinality data (like millions of files) and single-service data in the application DB instead. Centralize org and resource roles plus global flags like issuperadmin or isbanned; send ephemeral request data like IP or time of day as context facts.

Verified resolution: Before pushing data into Oso Cloud, sort it: roles and global attributes go to Oso Cloud, high-cardinality or fast-changing data stays in your DB, and request-scoped values like the client IP or IDP token claims ride along as context facts that live only for the request. Syncing everything centrally buys you drift and sync jobs you did not need.

Source URL: https://www.OSOHQ.COM/docs/develop/facts/overview

Not specified by the original author.

TL;DR

Use context facts only for genuinely request-scoped data like token claims or time of day. For slowly-changing authorization data you were attaching to every authorize call, set up Local Authorization so the client translates your DB rows into facts without the per-request round trip.

Steps

1. Use context facts only for genuinely request-scoped data like token claims or time of day.
2. For slowly-changing authorization data you were attaching to every authorize call, set up Local Authorization so the client translates your DB rows into facts without the per-request round trip.

When to use

You are seeing this: Context facts are passed with each authorize call (in the TypeScript SDK as an optional fourth argument) and exist only for the request, which is perfect for IDP claims or ephemeral attributes. Use this skill when you run into "Context facts cost network traffic on every Oso Cloud request".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (Send data as context facts, Oso Cloud): documents a gotcha that trips agents feeding data to authorization checks. Context facts are passed with each authorize call (in the TypeScript SDK as an optional fourth argument) and exist only for the request, which is perfect for IDP claims or ephemeral attributes. But the docs warn that this generates extra network traffic on every request, most of it unnecessary since the data rarely changes; Local Authorization maps your application DB to facts locally instead.

Verified resolution: Use context facts only for genuinely request-scoped data like token claims or time of day. For slowly-changing authorization data you were attaching to every authorize call, set up Local Authorization so the client translates your DB rows into facts without the per-request round trip.

Source URL: https://www.osohq.com/docs/learn/guides/adopt-local-authorization/data-as-context-facts