docs: update database-logic.md

- Fixed typos
- Updated info about `misc` and `environment_misc` fields
- Added more info about `environment_compatible` and what "Hardware"
  means in the dashboard
- Added info about the `output_files` column of Tests table

Closes #403

backend/docs/database-logic.md

@@ -36,31 +36,35 @@ a set of patches on top."
 Tests are linked to a build
 
 Important thing to look at the tests table is the `path` column, which is the
-type of test that it is performing.They will be split in dots, which means that
-is a child test from that test. `eg: boot.start` is a child of `boot`
+type of test that it is performing. They will be split by dots, which means that
+it is a child test from that test. `eg: boot.start` is a child of `boot`
 
 - `start_time` is the time that a test has started, we can use that to graph
  X-Axis graphs of tests over time
 
-- `status` Column show a status that can be `PASS` `SKIP` or `ERROR`
+- `status` column show a status that can be `PASS` `SKIP` or `ERROR`
 
-- `misc` - It is important to notice that the `misc` field can show the 
-error message in case of an error
+- `misc` a JSON field that is used to store miscellaneous data about the test like
+archicture, compiler, runtime, kernel type, etc. However, it does not have a fixed
+structure, and therefore can contain any type of information the CI system finds
+useful to store. It's possible to note this phenomenon when comparing the misc field
+between origins. The `misc` field might have data related to errors, but's generally
+not used since it's unreliable
 
-eg:
+example of a typical `misc` field of Maestro:
 ```json
 {
-  "arch": "arm64",
+  "arch": "x86_64",
+  "runtime": "lava-collabora",
   "compiler": "gcc-12",
-  "error_msg": "Invalid TESTCASE signal",
-  "error_code": "Test",
-  "kernel_type": "image"
+  "kernel_type": "bzimage"
 }
 ```
 
-- `environtment_misc` a JSON field that we can use for things about the environment
+- `environment_misc` a JSON field that we can use for things about the environment
 like detecting the platform, this is not set in stone and can change,
-so we should double check the validation
+so we should double check the validation. On Maestro it's expected that `platform` should
+be a field inside the `environment_misc` JSON.
 
 ```json
 {
@@ -69,23 +73,50 @@ so we should double check the validation
 }
 ```
 
->NOTE: The contents of the `misc` field is not standardized, and shouldn't
->be relied upon to ever be used consistently by more than one
+>NOTE: The contents of the columns `misc` and `environment_misc` are not standardized, and
+>shouldn't be relied upon to ever be used consistently by more than one
 >CI system ("origin"), or even by the originating CI system itself, over time.
 >The most it could be used for is a proof-of-concept.
 
-In the tests table, the `environment_compatibles` column contains a 
-sorted list of strings starting with the exact name of the machine, followed 
-by an optional list of boards it is compatible with sorted from most compatible 
-to least.
-
->NOTE: For more information about `environment_compatibles` these resources can 
-be used as a reference:
+- `environment_compatible` contains a sorted list of strings starting with the exact
+name of the machine, followed by an optional list of boards it is compatible with sorted
+from most compatible to least.
+
+>NOTE: The concept of "Hardware" used througout the dashboard also includes
+>the `platform` found in the `environment_misc` column. Up to this point, the rule is
+>to prioritize `platform` over `environment_compatible` since, at least on Maestro,
+>`platform` provides a more informative representation of the hardware used during the
+>test/boot/build. This, however, does not apply to the Hardware Listing and Details pages
+> that still prioritize the `environment_compatible` over `platform`
+>
+>For more information about `environment_compatible` these resources can
+>be used as a reference:
 > - [Platform Identification](https://docs.kernel.org/devicetree/usage-model.html#platform-identification)
 > - [Compatible Description](https://github.com/kernelci/kcidb-io/blob/21ddf852d1de6740e8fdf3696d9ddd8b3fd53bcc/kcidb_io/schema/v04_05.py#L611)
 
+- `output_files` is a JSON field that has an array of objects, each of them having data about
+the artifacts generated by the test. The Builds table also has an `input_files` column that respects
+the same structure
+
+```json
+[
+   {
+      "url":"https://storage.kernelci.org/broonie-sound/for-next/v6.11-rc3-218-gc76d5dfbfc97/arm64/defconfig/gcc-12/lab-broonie/lava-meson-sm1-s905d3-libretech-cc.json",
+      "name":"lava_json"
+   },
+   {
+      "url":"https://storage.kernelci.org/broonie-sound/for-next/v6.11-rc3-218-gc76d5dfbfc97/arm64/defconfig/gcc-12/lab-broonie/kselftest-alsa-meson-sm1-s905d3-libretech-cc.txt",
+      "name":"txt"
+   },
+   {
+      "url":"https://storage.kernelci.org/broonie-sound/for-next/v6.11-rc3-218-gc76d5dfbfc97/arm64/defconfig/gcc-12/lab-broonie/kselftest-alsa-meson-sm1-s905d3-libretech-cc.html",
+      "name":"html"
+   }
+]
+```
+
 
 ## Revision
 
 Revision has no respective table, but it is a collection of checkouts with
-the same `git_commit_hash` and `patchset_hash`. But `patchset_hash` is not commmonly used these days.
+the same `git_commit_hash` and `patchset_hash`. But `patchset_hash` is not commonly used these days.