Payload Structure
Payloads carry the actual knowledge data in an event, passed as a JSON object in the payload field.
Recommended Format
Use a flat object with topic and value keys:
{
"payload": {
"topic": "user_preference",
"value": "dark mode"
}
}The topic field helps the wisdom graph index and cluster related knowledge. The value field holds the actual content.
Good Payloads
Keep payloads flat and descriptive:
{ "topic": "api_rate_limit", "value": "1000 requests per minute" }{ "topic": "deployment", "value": "v2.3 deployed to production", "environment": "prod" }{ "topic": "user_feedback", "value": "prefers shorter responses", "rating": 4 }Adding extra flat keys alongside topic and value is fine. The admission pipeline indexes topic and value first, then scans additional keys.
Bad Payloads
Avoid deep nesting. The admission pipeline flattens nested objects, which can lose structure:
{
"user": {
"preferences": {
"theme": {
"mode": "dark",
"accent": "blue"
}
}
}
}Instead, store each piece as a separate event or flatten the structure:
{
"topic": "theme_mode", "value": "dark" }
}{
"topic": "theme_accent", "value": "blue" }
}Constraints
| Rule | Limit |
|---|---|
| Max payload size | 256 KB |
| Max key depth | 3 levels (recommended) |
| Encoding | UTF-8 JSON |
Payloads exceeding 256 KB are rejected at the admission stage. Split large data across multiple events instead.