Program trust policy
Where trust is set: event admission, the program trust policy with allowed_sources and minimum_trust, the rule trust floor and environment liability caps.
Trust says how much Orishare believes an event or command. Every admitted fact carries a level, weakest first:
| Level | Comes from |
|---|---|
anonymous_claim | A customer event in an anonymous session |
customer_claim | A customer event in an authenticated session (at most this, from a browser) |
merchant_asserted | Your backend with a secret key |
verified_evidence | A connector that verifies the business object (planned) |
legacy_unknown marks history from before trust was recorded; it satisfies no floor.
Trust is set in four places. Each one only narrows; none can raise the trust of a fact.
1. Event admission
Per event definition, with PATCH /v1/event_definitions/{id}: minimum_trust refuses weaker
admissions of that event, and client_allowed decides whether browsers and apps may send it at
all. Purchases, refunds and other money events stay server-only.
2. The program trust policy
Every native program version carries a trust policy. This is where allowed_sources and
minimum_trust live:
{
"trust": {
"minimum_trust": "merchant_asserted",
"allowed_sources": ["secret_key_event", "operator_command"],
"on_insufficient": "ignore",
"liability_caps": [],
"recognition_caps": [],
"allow_legacy_unknown": false
}
}| Field | Meaning |
|---|---|
minimum_trust | The weakest trust a contribution may have to count. |
allowed_sources | Which channels may contribute: publishable_event, secret_key_event, verified_connector, operator_command, customer_command, import, program_transition, schedule. At least one. |
on_insufficient | ignore drops a contribution below the floor; progress_without_reward records progress but pays nothing. |
liability_caps | Per trust level, currency, scope (customer or environment) and window (day, month, lifetime): the most spendable value that trust may create (maximum_minor). |
recognition_caps | Per trust level, how many contributions or how much value counts per period or day. Streaks, badges, quests, levels and leaderboards apply them. |
allow_legacy_unknown | Always false. |
A browser-fed habit program might allow publishable_event at customer_claim with a small
recognition cap (for a daily streak, { "trust": "customer_claim", "per": "day", "contributions": 1 }
counts one browser contribution a day) and no spendable reward; a purchase program allows only secret_key_event at
merchant_asserted. Read the policy with GET /v1/programs/{id}/versions/{version_id}; it
changes only by publishing a new version.
3. The rule trust floor
A v2 rule states only a floor, as trust: { minimum }:
{ "trust": { "minimum": "merchant_asserted" } }Rules never list sources. When the triggering fact is weaker than the minimum, the rule applies
nothing and the execution records trust_insufficient. See
rule examples 04 and 05.
4. Environment liability caps
GET /v1/trust_policy and PATCH /v1/trust_policy (with If-Match on the environment revision)
hold the environment-wide monetary_currencies and caps: the total spendable value each trust
level may create per customer or per environment, per day, month or lifetime. Client activity can
create spendable value only under such a cap; the default allowance is zero. Caps are enforced
atomically with the effects, and existing consumption is kept when a cap changes.
Simulation does not grant trust
POST /v1/rules/{id}/simulate accepts a trust level so you can test both sides of a floor. The
simulated level never establishes trust for a live event or command.