docs: hide temporal internals from API docs
This commit is contained in:
agumpandey
@@ -49,10 +49,6 @@ Provide conversation messages for Mem0 to extract memories from. At least one en
|
||||
| `run_id` | string | No* | Associates the memory with a run. |
|
||||
| `app_id` | string | No* | Associates the memory with an app. |
|
||||
| `metadata` | object | Optional | Custom key/value metadata (e.g., `{"topic": "preferences"}`). |
|
||||
| `timestamp` | integer | Optional | Unix timestamp used to anchor imported or historical memories. |
|
||||
| `observation_date` | string | Optional | Original conversation date (`YYYY-MM-DD`) for temporal grounding. |
|
||||
| `observation_datetime` | string | Optional | Original conversation datetime for more precise temporal grounding. |
|
||||
| `timezone` | string | Optional | IANA timezone used when resolving relative dates. |
|
||||
| `infer` | boolean (default `true`) | Optional | Set to `false` to skip inference and store the provided text as-is. |
|
||||
|
||||
> \* At least one entity ID (`user_id`, `agent_id`, `app_id`, or `run_id`) is required.
|
||||
@@ -87,7 +83,3 @@ The request is queued for background processing. The response contains an `event
|
||||
<Info>
|
||||
Poll the event status via `GET /v1/event/{event_id}/`. Status will be `SUCCEEDED` or `FAILED` once processing completes.
|
||||
</Info>
|
||||
|
||||
<Note>
|
||||
Some deployments run temporal enrichment in a follow-up async step. In that mode, the add event can complete successfully before temporal search fields are fully available on later searches.
|
||||
</Note>
|
||||
|
||||
@@ -19,31 +19,6 @@ The `filters` object supports complex logical operations (AND, OR, NOT) and comp
|
||||
|
||||
Pass `page` and `page_size` as query parameters to paginate through results.
|
||||
|
||||
## Temporal fields on `get_all`
|
||||
|
||||
`get_all` returns the **stored** memory record. For temporally enriched memories, that can include top-level fields such as:
|
||||
|
||||
- `event_date`
|
||||
- `event_start`
|
||||
- `event_end`
|
||||
- `time_precision`
|
||||
- `timezone`
|
||||
- `polarity`
|
||||
- `temporal_relation`
|
||||
- `state_key`
|
||||
- `plan_status`
|
||||
|
||||
These are stored memory attributes, not search-time interpretation fields.
|
||||
|
||||
`get_all` does **not** add search-only fields such as:
|
||||
|
||||
- `effective_plan_status`
|
||||
- `temporal_surface`
|
||||
- `reference_date_used`
|
||||
- `score_breakdown`
|
||||
|
||||
Those fields belong to `search`, where Mem0 interprets a query in context.
|
||||
|
||||
<CodeGroup>
|
||||
```python Code
|
||||
memories = client.get_all(
|
||||
@@ -75,16 +50,7 @@ memories = client.get_all(
|
||||
"metadata": {},
|
||||
"categories": [],
|
||||
"created_at": "2024-07-01T12:00:00Z",
|
||||
"updated_at": "2024-07-01T12:00:00Z",
|
||||
"event_date": "2024-07-01",
|
||||
"event_start": "2024-07-01",
|
||||
"event_end": "2024-07-10",
|
||||
"time_precision": "interval",
|
||||
"timezone": "UTC",
|
||||
"polarity": "positive",
|
||||
"temporal_relation": "during",
|
||||
"state_key": null,
|
||||
"plan_status": "pending"
|
||||
"updated_at": "2024-07-01T12:00:00Z"
|
||||
},
|
||||
{
|
||||
"id": "a2b8c3d4-5e6f-7g8h-9i0j-1k2l3m4n5o6p",
|
||||
@@ -93,16 +59,7 @@ memories = client.get_all(
|
||||
"metadata": {},
|
||||
"categories": [],
|
||||
"created_at": "2024-07-05T15:30:00Z",
|
||||
"updated_at": "2024-07-05T15:30:00Z",
|
||||
"event_date": null,
|
||||
"event_start": null,
|
||||
"event_end": null,
|
||||
"time_precision": null,
|
||||
"timezone": null,
|
||||
"polarity": null,
|
||||
"temporal_relation": null,
|
||||
"state_key": null,
|
||||
"plan_status": null
|
||||
"updated_at": "2024-07-05T15:30:00Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -18,20 +18,9 @@ The `filters` object supports complex logical operations (AND, OR, NOT) and comp
|
||||
- `icontains`: Case-insensitive containment check
|
||||
- `*`: Wildcard character that matches everything
|
||||
|
||||
## Temporal fields in V3 responses
|
||||
## Temporal reasoning in V3 responses
|
||||
|
||||
When Temporal Reasoning is enabled for a query, search results can include additional **top-level** fields such as:
|
||||
|
||||
- `memory_type`
|
||||
- `event_date`
|
||||
- `event_start`
|
||||
- `event_end`
|
||||
- `plan_status`
|
||||
- `effective_plan_status`
|
||||
- `time_precision`
|
||||
- `temporal_surface`
|
||||
- `reference_date_used`
|
||||
- `score_breakdown.temporal_boost`
|
||||
Temporal Reasoning is applied internally during retrieval. Search responses keep the normal result shape.
|
||||
|
||||
### Search parameter defaults
|
||||
|
||||
@@ -78,7 +67,7 @@ related_memories = client.search(
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
### Temporal example
|
||||
### Temporal query example
|
||||
|
||||
<CodeGroup>
|
||||
```python Platform API Example
|
||||
@@ -97,15 +86,6 @@ results = client.search(
|
||||
"memory": "Finished the Q1 product review on March 10, 2025.",
|
||||
"user_id": "alice",
|
||||
"score": 0.91,
|
||||
"memory_type": "event",
|
||||
"event_date": "2025-03-10",
|
||||
"event_start": "2025-03-10",
|
||||
"event_end": "2025-03-10",
|
||||
"plan_status": null,
|
||||
"effective_plan_status": null,
|
||||
"time_precision": "day",
|
||||
"temporal_surface": "Mar 10, 2025",
|
||||
"reference_date_used": "2025-03-21",
|
||||
"metadata": {},
|
||||
"categories": [],
|
||||
"created_at": "2025-03-10T00:00:00Z",
|
||||
@@ -116,10 +96,6 @@ results = client.search(
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
<Note>
|
||||
Temporal fields are most useful on `search`. The paginated `get_all` endpoint remains a broader retrieval surface and does not mirror the full time-aware search result shape.
|
||||
</Note>
|
||||
|
||||
<CodeGroup>
|
||||
```python Wildcard Example
|
||||
# Using wildcard to match all run_ids for a specific user
|
||||
|
||||
Reference in New Issue
Block a user