Subject memory
Pass your customer id as subject_ref and Ward links decisions about the same customer. The next statement for that customer is read against the profile the earlier ones built (usual inflows, counterparties, declared income), so a change stands out.
Memory is kept only with consent: send "subject_consent": true on the call (you attest the customer consented at your onboarding), or record consent once:
curl -X PUT https://api.mandatelabs.ai/api/v1/subjects/cust_1042 \
-H "X-API-Key: $WARD_API_KEY" -H "Content-Type: application/json" \
-d '{"consent": true, "consent_method": "onboarding_terms_v3", "occupation": "nurse", "monthly_income": 3200, "country": "USA", "customer_type": "individual"}'
client.subjects.update("cust_1042", consent=True, consent_method="onboarding_terms_v3", monthly_income=3200)
await client.subjects.update("cust_1042", { consent: true, consent_method: "onboarding_terms_v3", monthly_income: 3200 });
| Endpoint | Does |
|---|---|
GET /api/v1/subjects/{ref} |
What Ward has observed about the customer |
PUT /api/v1/subjects/{ref} |
Record consent and declared data (occupation, income, country, customer type) |
DELETE /api/v1/subjects/{ref} |
Erase the customer's memory (right to erasure) |
Without consent the decision still runs; it is just not linked. When a subject is known, the envelope's subject field carries the profile, and needs asks for what would help (for example a declared income).