Hosted infer=true ADD — Event result mapping and bounded cleanup semantics

[VernaleQQQ]

Hi Mem0 team,

We are validating a synthetic, non-sensitive Hosted memory flow using:

POST /v3/memories/add/
with infer=true

followed by:

GET /v1/event/{event_id}/

One synthetic ADD returned HTTP 200 and an async event was accepted.
A subsequent GET EVENT also returned HTTP 200.

Our client-side decoder rejected the Event response, but the exact rejected
field was not retained. We therefore are not treating this as a provider bug.

No memory ID was established and no DELETE was attempted.

Before running another controlled test, we would like to clarify the
normative Hosted contract for Event results and bounded cleanup.

Could you please clarify:

1. For each Event status:
   PENDING
   RUNNING
   SUCCEEDED
   FAILED

   when may results be:

   • absent
   • null
   • []
   • non-empty array?

2. For infer=true ADD, what is the exact schema of each
   GET /v1/event/{event_id}/ results element?

3. Which field in a SUCCEEDED Event result maps to the authoritative
   Memory API memory ID?

4. Is that memory ID guaranteed to be a UUID?

5. Does a SUCCEEDED Event enumerate all memories created by that ADD?
   Can it also reference pre-existing or reused memories?

6. Can a FAILED Event still leave partially created or later-visible
   memories?

7. What fields should be used to prove that a returned memory belongs
   to the exact user / agent / run that initiated the ADD?

8. If the Event result cannot be decoded or does not expose memory IDs,
   what is the recommended bounded recovery method for discovering
   memories created by that specific ADD?

9. For scoped discovery, when can paginated Get Memories using
   user/agent/run/metadata filters be considered complete?

10. After a correction/update, does PUT merge or replace metadata?
    Which user/agent/run provenance fields are preserved?

11. For:
    DELETE /v1/memories/{memory_id}/?delete_linked=false

    what observable condition should be treated as deletion completion
    across GET, list, and search?

12. Are there eventual-consistency or temporal-enrichment delays after
    Event SUCCEEDED that can affect when newly created memories appear
    in GET/list/search?

If possible, a normative schema or fictional example responses for
PENDING, RUNNING, SUCCEEDED, and FAILED would be very helpful.

We are intentionally not making another Hosted call until the completed
result mapping and bounded cleanup semantics are clear.

Thank you.