#2355 changed the primary user experience of Tracee to be event oriented (previously events were considered internal and hidden from the user). Therefore:

1. The event schema needs to be formalized and stabilized. Since it's no longer internal.
2. The event structure needs to be generalized. Since events are will now be used for detections, captures and more.

Following is the updated event schema based on the comments below:

1. timestamp
2. name
3. id - machine readable id (integer). Note: current event id isn't good since it is architecture specific
4. // version - use semver where major is a breaking change in the event (e.g. one of the event's fields under data has been changed or removed), minor is a non breaking change (e.g. a new field was added to the event under data) and patch (e.g. a bug fix). Since this data is static, we may remove this or make optional
5. // tags - since this data is static, we may remove this or make optional
6. labels - doesn't exist. For future use.
7. policies
   1. matched
   2. actions - doesn't exist, for future use - list of actions taken (currently the only action we have is print).
8. workload
   1. process
      1. executable
         1. path
         2. name - the binary name (basename of the path) - doesn't exist, consider adding (in another issue)
      2. uniqueId - unique id of the process
      3. pid
      4. hostPid
      5. executionTime - time of last exec. Doesn't exist, consider adding (in another issue)
      6. realUser
         1. id
         2. name - doesn't exist, consider adding (in another issue)
      7. user - effective user. Doesn't exist, consider adding (in another issue)
         1. id
         2. name
      8. ancestors - process ancestors array. Only direct parent will be populated by default with the following fields:
         1. uniqueId
         2. pid
         3. hostPid
         4. Other ancestor fields may be populated by threat detection events
      9. thread
         1. startTime
         2. name (aka "comm")
         3. tid
         4. hostTid
         5. capabilities - doesn't exist, consider adding (in another issue)
         6. syscall - the syscall that triggered this event
         7. compat - boolean. moved from flags.compat
         8. userStackTrace - if enabled, will be here
   2. container
      1. id
      2. name
      3. image
         1. id
         2. repoDigest
         3. name
      4. isRunning - boolean. moved from flags
      5. startTime - Timestamp of container start time. Doesn’t exist. Will replace started
      6. pid - entrypoint's pid. Doesn’t exists, consider adding
   3. k8s
      1. pod
         1. name
         2. uid
         3. labels
      2. namespace
         1. name
9. data
   1. Any relevant field (per-event schema)
   2. returnValue (if relevant will appear here)
10. threat (if relevant will appear here) - static data about threats (can be omitted)
    1. description
    2. mitre
       1. tactic
          1. name
       2. technique
          1. name
          2. id
    3. severity
11. triggeredBy (will appear on threat detection events)
    1. name
    2. id
    3. data

We also discussed versioning the event schema, but not including the version with each event, for efficiency.