Trust contexts for producers

20+ documented contexts

Life-area scopes — ten primary domains and ten lens views; enable primaries you emit; consumers request allowed contexts on reports.

Audience: trust producers enabling one or more life-area contexts on PTI.

Outcomes

• Declare which of the 20+ documented contexts you emit signals for
• Set exactly one primary context for partner widgets
• Enable ingest channels per context and read tcu_mtd in the hub API

Portable trust is context-scoped: a commerce platform and a lender on the same PTI tenant operate in different life areas (merchant vs lending). Your partner profile declares which contexts you produce signals for; every event, CSV row, TCU charge, and Pulse chart respects that scope.

---

One partner, many contexts

Concept	Rule
Partner	One per organization (partner_id)
Trust context	One enabled life-area scope per row in your partner profile
Primary context	Exactly one is_primary — drives default headline score in partner widgets
Connector	Single profile; ingest channels per context (webhook, API, CSV)

You do not need separate partner IDs per context unless your contract explicitly requires it.

---

Context tiers

TumiTrust documents 20+ trust contexts — 10 primary life areas and 10 lens cross-cutting views. Partners and institutions enable the contexts their contract covers.

Scope	Framing
Primaries	Life-area contexts — lending, rental, employment, and more
Lenses	Cross-cutting views — risk_compliance, digital_platform, civic, and more

Housing, employment, insurance, agriculture, and civic contexts are not implied as simultaneous launch scope in public materials unless your institution contract explicitly enables them.

---

All documented trust contexts

These IDs are shared across producer ingest, consumer report contexts[], and Pulse filtering. Enable only contexts your contract covers.

#	Context ID	Primary / lens	Label	Typical producers
1	lending	Primary	Lending & Borrowing	Banks, MFIs, credit platforms
2	rental	Primary	Rental & Housing	Landlords, lease platforms
3	employment	Primary	Employment & Work	Employers, HR tech
4	insurance	Primary	Insurance & Risk	Insurers, brokers
5	merchant	Primary	Merchant & Business	Commerce, marketplaces, retail
6	partnership	Primary	Business Partnerships	B2B networks, joint ventures
7	supplier	Primary	Supply Chain	Vendors, procurement platforms
8	informal_sector	Primary	Informal Economy	Community networks, informal commerce
9	agricultural	Primary	Agriculture & Farming	Agri co-ops, farm finance
10	remittance	Primary	Money Transfer	Remittance, mobile money
11	education	Lens	Education & Skills	Schools, training platforms
12	health	Lens	Health & Care	Clinics, care networks
13	family	Lens	Family & Household	Household finance, dependents
14	civic	Lens	Civic & Public Life	NGOs, civic programs
15	digital_platform	Lens	Digital & Platform Work	Gig apps, creator platforms
16	mobility	Lens	Mobility & Logistics	Delivery, transport operators
17	utilities	Lens	Utilities & Subscriptions	Telco, utility billing
18	creative	Lens	Creative & Gigs	Creative networks, short contracts
19	faith_mutual_aid	Lens	Faith & Mutual Aid	Faith groups, mutual aid circles
20	risk_compliance	Lens	Risk & Compliance	Insurers, banks, compliance programs

Producer vs consumer use

Role	What to configure
Producer	Enable primary contexts you emit (rows 1–10). Enable lens contexts (11–20) only when your contract covers direct lens emission — otherwise they are derived for consumer reports.
Consumer	Request any allowed context in contexts[] when generating a trust report — see Trust platform API.

---

Configure in the hub

During onboarding

Wizard step Contexts — multi-select checkboxes for every life area you will emit signals for. For producers, selections create enabled trust contexts when you register the partner profile.

After onboarding

API (authenticated institution session):

GET /institution/<slug>/api/partner/trust-contexts/

Response includes per context:

Field	Meaning
context_id	Slug (merchant, lending, …)
is_primary	Headline context for partner UI
is_enabled	Whether events are accepted
entity_type	PTI subject type for linking
ingest_channels	Webhook / API / CSV flags
tcu_mtd	TCU consumed this period for this context

Update:

PATCH /institution/<slug>/api/partner/trust-contexts/
Content-Type: application/json

{
  "contexts": [
    { "context_id": "merchant", "is_primary": true, "is_enabled": true },
    { "context_id": "lending", "is_primary": false, "is_enabled": true },
    { "context_id": "mobility", "is_primary": false, "is_enabled": true }
  ]
}

---

Confirmation workflow

Use this sequence when adding a new context to a live partner:

Step	Action	Confirmation
1	PATCH trust-contexts to enable context	GET returns is_enabled: true
2	Add event types + trigger rules for that context in Event catalog	Preview API shows correct context_ids
3	Enable ingest channel (webhook or CSV)	Connector panel shows channel active
4	Send test event (or CSV row)	Pulse Insight Studio shows event with context_id
5	Review TCU	Billing breakdown shows row for context + operation

Disabling a context does not delete historical events; new events targeting that context are rejected with a clear validation error.

---

Validation rules (what integrators should expect)

• Event context must be in your enabled context list
• event_type must exist in your catalog with trigger rules for that context
• CSV batches are single-context — pick context before upload
• TCU and invoices attribute usage by context_id where supported

---

Related

• Connector configuration
• CSV data upload
• Trust platform API — consumer contexts[] on reports
• For partners