[Spike] Explore potential state and simulated (start / event) time

[AJamesPhillips]

Currently

• We have some events, states, etc which have a custom_created_at date far before the actual created_at date.
• Some of these, that custom_created_at date is valid because there are downstream inferences / decisions / actions / perceptions etc and that the use of that data with in the tool benefits from custom_created_at
• Some of the functionality that custom_created_at is actually that of event_datetime / start_datetime
• How do simulated datetime fields fit with the following requirements / observations:

---

For things that could happen in the future there are a few dimensions:

1. Existence dimension:
   • Happens in future (high probability + high conviction)
   • Could happen in future (high/low probability + low conviction)
   • Won't happen in future (low probability + high conviction)
   • 1b. Existence continuation:
   • i.e. is this an ongoing process (what some might call an ongoing "event") e.g. like "@@20aee689-d7e1-41fd-8f50-ecc6d69dae26"
2. Temporal dimension:
   • at some time
   • at Z time +/- M (M ~ 1 / conviction)
   • this may be multiple times, e.g. could happen on 12th at 12:00 +/- 10 minutes or 31st +/- 3 days.
3. Dependencies temporal dimension:
   • after P time +/- R is really saying after event X (correct?)
   • before event Y
   • this is said either as a different form of "after event X"
   • or because after event Y, then event X will not be applicable / possible.

Copied from 1ce18181-1b9a-46e2-aec7-34577a16a801

---

[AJamesPhillips]

The application and my thinking has evolved and there are a few parts to this collection of observations:

1. The existence dimension is now modelled (for now) by copying the statev2 TemporalUncertainty + Prediction elements and putting under the "Existence Prediction". This is ok for now but:
   • this is just a state like a statev2 node.
   • as such I think we should nest a statev2 node and have that represent this node's existence state.

Additionally the temporal uncertainty interface can capture all these elements of:

• Happens in future (high probability + high conviction)
• Could happen in future (high/low probability + low conviction)
• Won't happen in future (low probability + high conviction)
• 1b. Existence continuation:
  • i.e. is this an ongoing process (what some might call an ongoing "event") e.g. like "@@wc868095689997596"

And can also capture the points under "point 2" of:

• at some time
• at Z time +/- M (M ~ 1 / conviction)

However it can not currently capture:

• multiple times, e.g. could happen on 12th at 12:00 +/- 10 minutes or 31st +/- 3 days.

To capture multiple possible values we would need to use the full StateV2 pattern AND the previous_VAP_set_ids #8

2. see above.

3. Dependencies of temporal dimension.

   • I suspect we will eventually handle this by computing over the graph
   • and secondly by allowing the computed values to influence not only the state value, but the existence prediction values as well.

[AJamesPhillips]

This is a valuable collection of scenarios to model but closing this issue as nothing specific and concrete to action.