diff --git a/g3/managed_store.cpp b/g3/managed_store.cpp
index b19b951..85f4dcf 100644
--- a/g3/managed_store.cpp
+++ b/g3/managed_store.cpp
@@ -583,7 +583,7 @@
             std::chrono::duration_cast<std::chrono::milliseconds>(
                 clockNow() - valueType->lastRefreshAt)
                 .count());
-        BMCWEB_LOG_ALWAYS << "MAX AGE AT THIS POINT: " << age_in_ms;
+        LOG(INFO) << "MAX AGE AT THIS POINT: " << age_in_ms;
         std::move(callback)(valueType->errorCode,
                             valueType->managedProperty.value(), age_in_ms);
       });
@@ -628,7 +628,7 @@
     const std::string& match_expression,
     ecclesia::EventSourceId event_source_id) {
   if (match_expression.empty()) {
-    BMCWEB_LOG_ALWAYS
+    LOG(WARNING)
         << "D-Bus match expression is empty. Invalid call to subscribe!";
     return;
   }
@@ -636,7 +636,7 @@
   if (requestContext.eventSourceIds == nullptr ||
       requestContext.request_type ==
           ManagedObjectStoreContext::RequestType::kQuery) {
-    BMCWEB_LOG_ALWAYS << "eventSourceIds is null. Invalid call to subscribe!";
+    LOG(WARNING) << "eventSourceIds is null. Invalid call to subscribe!";
     return;
   }
 
@@ -649,12 +649,12 @@
           ManagedObjectStoreContext::RequestType::kCancelSubscription) {
         // Erase the monitor
         signal_monitors_.erase(find_monitor);
-        BMCWEB_LOG_ALWAYS << "Erased D-Bus monitor for id: "
+        LOG(WARNING) << "Erased D-Bus monitor for id: "
                           << event_source_id.ToString();
         return;
       }
 
-      BMCWEB_LOG_ALWAYS << "D-Bus monitor already created for id: "
+      LOG(WARNING) << "D-Bus monitor already created for id: "
                         << event_source_id.ToString();
 
       // Record monitor id regardless of an existing subscription since
@@ -671,23 +671,23 @@
         sdbusplus::bus::match_t>(
         *system_bus_, match_expression,
         [event_source_id, this](sdbusplus::message_t&) {
-          BMCWEB_LOG_ALWAYS
+          LOG(INFO)
               << "Received dbus signal. Notifying Subscription service now!";
           auto status =
               subscription_service_->Notify(event_source_id, absl::OkStatus());
           if (status.ok()) {
-            BMCWEB_LOG_ALWAYS << "Notified successfully!";
+            LOG(INFO) << "Notified successfully!";
             return;
           }
-          BMCWEB_LOG_ALWAYS << "Error while sending notification: " << status;
+          LOG(WARNING) << "Error while sending notification: " << status;
           if (status.code() == absl::StatusCode::kNotFound) {
             absl::MutexLock lock(&signal_monitor_mutex_);
             signal_monitors_.erase(event_source_id);
-            BMCWEB_LOG_ALWAYS << "Erased D-Bus monitor for id: "
+            LOG(INFO) << "Erased D-Bus monitor for id: "
                               << event_source_id.ToString();
           }
         });
-    BMCWEB_LOG_ALWAYS << "D-Bus monitor created. Event Source id: "
+    LOG(INFO) << "D-Bus monitor created. Event Source id: "
                       << event_source_id.ToString();
   });
 
@@ -1025,7 +1025,7 @@
       cached_object->lastUsedAges->pop_front();
     }
 
-    BMCWEB_LOG_ALWAYS << "Object found in store. " << " Key: " << key_id
+    LOG(INFO) << "Object found in store. " << " Key: " << key_id
                       << " CurrentAge: "
                       << clockDurationMilliseconds(current_age)
                       << " Context: " << requestContext.toString()
@@ -1042,7 +1042,7 @@
 
     // Evict the object from store as it has become stale.
     if (is_object_stale) {
-      BMCWEB_LOG_ALWAYS << "Object has become stale! "
+      LOG(INFO) << "Object has become stale! "
                         << " service: " << keyType.serviceName
                         << " path: " << keyType.objectPath.str
                         << " interface: " << keyType.interface << " property: "
diff --git a/tlbmc/g3doc/debug/sensor_debug_guide.md b/tlbmc/g3doc/debug/sensor_debug_guide.md
new file mode 100644
index 0000000..00f03c8
--- /dev/null
+++ b/tlbmc/g3doc/debug/sensor_debug_guide.md
@@ -0,0 +1,209 @@
+# Sensor Debug Guide
+
+go/tlbmc-sensor-debug
+
+<!--*
+# Document freshness: For more information, see go/fresh-source.
+freshness: { owner: 'tlbmc-dev' reviewed: '2025-07-08' }
+*-->
+
+By default, tlBMC store will fail to create when sensor creation fails. Note
+that with traditional dbus-sensors daemons, sensor creation failures are silent
+and will only result in the objects not being created. This results in partial
+data being reported and hides missing sensors in the redfish tree unless they
+are directly queried by a client. tlBMC's behavior allows for verification that
+all TlbmcOwned sensors declared in Entity Manager Config files are successfully
+created and served by tlBMC.
+
+You can verify that tlBMC has failed to initialize by querying the tlBMC root,
+which may result in the following output:
+
+```
+root@HOSTNAME:~# curl localhost/redfish/tlbmc
+{
+  "error": {
+    "@Message.ExtendedInfo": [
+      {
+        "@odata.type": "#Message.v1_1_1.Message",
+        "Message": "The requested resource of type  named 'tlbmc' was not found.",
+        "MessageArgs": [
+          "",
+          "tlbmc"
+        ],
+        "MessageId": "Base.1.13.0.ResourceNotFound",
+        "MessageSeverity": "Critical",
+        "Resolution": "Provide a valid resource identifier and resubmit the request."
+      }
+    ],
+    "code": "Base.1.13.0.ResourceNotFound",
+    "message": "The requested resource of type  named 'tlbmc' was not found."
+  }
+}
+```
+
+This output indicates that tlBMC is currently disabled and will result in a
+fallback to traditional bmcweb. Note that sensor readings may not be present in
+this case if `SkipDbusRead` is configured in EM config files per sensor. This
+guide will describe some common methods for how to debug which sensors fail to
+be created in this situation.
+
+[TOC]
+
+## Check tlBMC Store Creation Failure Logs
+
+To verify that tlBMC has failed during creation of a sensor, we can check the
+bmcweb logs. To check logs, use the following command and expect similar output:
+
+```
+root@HOSTNAME:~# journalctl -u bmcweb | grep -i tlbmc
+...
+Jul 06 09:09:54 {HOSTNAME} bmcweb[1955026]: E0706 09:09:54.072554 1955026 webserver_main_setup.hpp:232] Cannot create tlBMC store!! Error: INTERNAL: Failed to find hwmon under /sys/bus/i2c/devices/i2c-1/1-001a - Disabling tlBMC
+```
+
+This log indicates a failure to create a sensor object in tlBMC, likely due to a
+failure to initialize a sensor which may indicate a real hardware failure.
+
+To find additional information about the exact sensor that is failing, you can
+utilize the bus and address information derived from the log at
+`/sys/bus/i2c/devices/i2c-{BUS}/{BUS}-00{ADDRESS}`. By checking the EM config
+files associated with this platform, you can find the sensor configuration
+associated with the given bus/address. Verifying that the bus/address is correct
+for the intended sensor is an important first step for debug.
+
+## Verify hwmon File Presence and Value
+
+Checking that the expected hwmon file is present on the machine is necessary to
+verify that sensor readings are working as intended. To do so, use the following
+commands and you should expect to see similar output:
+
+```
+root@HOSTNAME:~# ls /sys/bus/i2c/devices/i2c-{BUS}/{BUS}-00{ADDRESS}
+driver     hwmon      modalias   name       of_node    pec        subsystem  uevent
+```
+
+Failure to find the hwmon directory shown above could indicate a larger issue,
+such as a real hardware failure (see below).
+
+If the hwmon directory is present, you can verify the intended value of the
+sensor by checking the following:
+
+```
+root@HOSTNAME:~# ls /sys/bus/i2c/devices/i2c-{BUS}/{BUS}-00{ADDRESS}/hwmon/hwmon{*}/
+curr1_crit         curr3_input        in1_label          in3_lcrit_alarm    power2_label       temp2_crit_alarm
+curr1_crit_alarm   curr3_label        in1_lcrit          in4_crit           power3_input       temp2_input
+curr1_input        curr3_max          in1_lcrit_alarm    in4_crit_alarm     power3_label       temp2_lcrit
+curr1_label        curr3_max_alarm    in1_max            in4_input          power4_input       temp2_lcrit_alarm
+curr1_max          curr4_crit         in1_max_alarm      in4_label          power4_label       temp2_max
+curr1_max_alarm    curr4_crit_alarm   in1_min            in4_lcrit          subsystem          temp2_max_alarm
+curr2_crit         curr4_input        in1_min_alarm      in4_lcrit_alarm    temp1_crit         temp3_crit
+curr2_crit_alarm   curr4_label        in2_input          name               temp1_crit_alarm   temp3_crit_alarm
+curr2_input        curr4_max          in2_label          of_node            temp1_input        temp3_input
+curr2_label        curr4_max_alarm    in3_crit           power1_alarm       temp1_lcrit        temp3_lcrit
+curr2_max          device             in3_crit_alarm     power1_input       temp1_lcrit_alarm  temp3_lcrit_alarm
+curr2_max_alarm    in1_crit           in3_input          power1_label       temp1_max          temp3_max
+curr3_crit         in1_crit_alarm     in3_label          power2_alarm       temp1_max_alarm    temp3_max_alarm
+curr3_crit_alarm   in1_input          in3_lcrit          power2_input       temp2_crit         uevent
+```
+
+To find the file that corresponds to the sensor you are interested in, you can
+`cat` the value of the `{sensor_type}{*}_label` files to find one that matches
+the label in the EM config. For instance, if the sensor name in the EM config is
+`vout1_Name`, the value `vout1` will be present in one of `in1_label`,
+`in2_label`, `in3_label`, or `in4_label`. The sensor reading will be in the
+corresponding `in{*}_input` file. Verify that this is a well-formed sensor
+reading value as expected.
+
+## Enable allow_sensor_creation_failure in tlBMC Configuration
+
+The method described above has the disadvantage of only being able to diagnose a
+single sensor at a time. tlBMC conveniently provides an option to configure
+bypassing sensor creation failures while still providing useful information for
+debugging. We provide a setting in the tlBMC central configuration to
+`allow_sensor_creation_failure`.
+
+This setting allows tlBMC store to be created regardless of sensor creation
+failures. Valid sensors will still be served by tlBMC and debug information can
+be obtained from tlBMC debug paths such as:
+
+```
+root@HOSTNAME:~# curl localhost/redfish/tlbmc/AllSensors
+{
+...
+"error": {
+    "@Message.ExtendedInfo": [
+      {
+        "@odata.type": "#Message.v1_1_1.Message",
+        "Message": "Sensor temperature_{SENSOR_NAME} is not ready in tlBMC Store: Failed to read from input device: No such device or address; input device path: /sys/bus/i2c/devices/i2c-{BUS}/{BUS}-00{ADDRESS}/hwmon/hwmon{*}/temp{*}_input",
+        "MessageId": "Base.1.13.0.InternalError"
+      },
+      {
+        "@odata.type": "#Message.v1_1_1.Message",
+        "Message": "Sensor voltage_{SENSOR_NAME} is not ready in tlBMC Store: Read data can't be converted to a number: Invalid argument",
+        "MessageId": "Base.1.13.0.InternalError"
+      },
+      ...
+    ],
+    "code": "Base.1.8.GeneralError",
+    "message": "A general error has occurred. See Resolution for information on how to resolve the error."
+  }
+}
+```
+
+All sensor creation errors encountered during tlBMC store creation are combined
+in the AllSensors response following the
+[Redfish error message spec](https://redfish.dmtf.org/schemas/DSP0266_1.19.0.html#error-responses).
+
+To enable the `allow_sensor_creation_failure` feature, a change must be made
+similar to:
+https://gbmc-private-review.git.corp.google.com/c/meta-google-private/+/35823.
+Add/modify the entry corresponding with the desired platform to include:
+
+```
+sensor_collector_module { enabled: true allow_sensor_creation_failure: true }
+```
+
+Build and flash a bmcweb binary including this change to have the central config
+take effect.
+
+## Verify Real Hardware Failures
+
+For additional information to diagnose sensor failures, it may be helpful to
+check logs using `dmesg`. Consider using the following command and look for logs
+similar to the following:
+
+```
+root@HOSTNAME:~# dmesg | grep "Failed to register"
+[   92.520183] i2c i2c-{BUS}: Failed to register i2c client {DRIVER} at 0x{ADDRESS} (-16)
+```
+
+This indicates a failure to set up the device which could indicate a real
+failure or the device could have been occupied by another script or service
+during boot.
+
+Potential *short term* solutions in this case could be to:
+
+-   Manually bind the device using:
+
+    ```
+    root@HOSTNAME:~# echo "{BUS}-00{ADDRESS}" >
+    /sys/bus/i2c/drivers/{DRIVER}/bind
+    ```
+
+    If the device was temporarily occupied during boot, this may correctly set
+    up the device.
+
+-   Powercycle the machine: rebooting has fixed sensor instantiation in some
+    cases
+
+    If either approach above is used, a bug should still be filed and the issue
+    should be reproduced. This flakiness in sensor creation could mask
+    underlying problems e.g. b/428930642.
+
+Note: In some cases, it may be expected to see some `Failed to register i2c
+client` logs, for instance in the case of having sensors configured in the EM
+config for second-source boards. These sensors may be expected to fail to create
+if the FRU on the machine does not correspond with the second-source FRU. Also
+note that expected dmesg error logs are only possible when these sensors are not
+supported by tlBMC. If tlBMC were to support the second source board sensors, a
+separate config would have to be made to logically separate these sensors and
+probe accordingly.
diff --git a/tlbmc/g3doc/general/redfish_resource_ownership_model.md b/tlbmc/g3doc/general/redfish_resource_ownership_model.md
new file mode 100644
index 0000000..eff23fe
--- /dev/null
+++ b/tlbmc/g3doc/general/redfish_resource_ownership_model.md
@@ -0,0 +1,364 @@
+# tlBMC Redfish Resource Ownership Model
+
+go/tlbmc-redfish-resource-ownership
+
+<!--*
+# Document freshness: For more information, see go/fresh-source.
+freshness: { owner: 'tlbmc-dev' reviewed: '2025-05-13' }
+*-->
+
+[TOC]
+
+Note: This is an evolving document and definitions may shift as the scope of
+tlBMC increases.
+
+tlBMC ownership of a redfish resource happens when a redfish URL is sent to the
+tlBMC app rather than the traditional gBMCweb app. As described in
+go/tlbmc-smart-routing, an incoming redfish query may be routed to traditional
+bmcweb or to the tlBMC app depending on if the resource is "owned" by tlBMC,
+this is called smart routing. In the case of tlBMC ownership, a query being sent
+to tlBMC means that tlBMC is providing the query response based on the internal
+representation of the requested object after tlBMC has parsed the EM config.
+There are no dbus calls being made or interactions with other daemons to return
+this response.
+
+There are three possible models for a redfish resource to be "owned" by tlBMC
+today. This document describes the extent to which tlBMC may have ownership over
+a resource.
+
+## Fully Owned
+
+### Chassis
+
+Chassis resources onboarded to tlBMC are detected and fully owned. In this case,
+FRUs are detected by tlBMC over I2C scan and the Redfish response is provided by
+the tlBMC backend. Every part of the Chassis response comes from tlBMC,
+including Fru info received from the eeprom of the device and links to
+associated Chassis, Cables, Processors, or Drives which are configured in the EM
+config.
+
+An example can be seen from this config:
+
+```json
+{
+  "Name": "foo",
+  "ProbeV2": {
+    "IpmiFru": {
+      "BOARD_PRODUCT_NAME": "Foo"
+    }
+  },
+  "ResourceType": "RESOURCE_TYPE_BOARD",
+  "Exposes":[
+    {
+      "Name": "Foo Downstream Port",
+      "Label": "PE0",
+      "Type": "PortDownstream"
+    },
+    {
+      "Type": "MAX31725",
+      "Bus": 1,
+      "Address": "0x4c",
+      "Name": "max31725_0",
+      "Name1": "max31725_1",
+      "TlbmcOwned":true
+    }
+  ],
+  "Asset": {
+    "Manufacturer": "$BOARD_MANUFACTURER",
+    "Model": "$BOARD_PRODUCT_NAME",
+    "PartNumber": "$BOARD_PART_NUMBER",
+    "SerialNumber": "$BOARD_SERIAL_NUMBER"
+  }
+}
+```
+
+The above config might produce the following redfish response, which contains
+fields fully populated by tlBMC, requiring no additional dbus calls or
+interactions with other daemons.
+
+```json
+{
+  "@odata.id": "/redfish/v1/Chassis/Foo",
+  "@odata.type": "#Chassis.v1_17_0.Chassis",
+  "Assembly": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/Assembly"
+  },
+  "Certificates": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/Certificates"
+  },
+  "ChassisType": "Module",
+  "Drives": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/Drives"
+  },
+  "EnvironmentMetrics": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/EnvironmentMetrics"
+  },
+  "Id": "Foo",
+  "Links": {
+    "ComputerSystems": [
+      {
+        "@odata.id": "/redfish/v1/Systems/system"
+      }
+    ],
+    "Contains": {
+      "@odata.id": "/redfish/v1/Chassis/Bar"
+    },
+    "ManagedBy": [
+      {
+        "@odata.id": "/redfish/v1/Managers/bmc"
+      }
+    ]
+  },
+  "Manufacturer": "Foo_Manufacturer",
+  "Memory": {
+    "@odata.id": "/redfish/v1/Systems/system/Memory"
+  },
+  "Model": "Foo_Model",
+  "Name": "Foo",
+  "PCIeDevices": {
+    "@odata.id": "/redfish/v1/Systems/system/PCIeDevices"
+  },
+  "PCIeSlots": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/PCIeSlots"
+  },
+  "PartNumber": "1111111-11",
+  "Power": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/Power"
+  },
+  "PowerState": "On",
+  "PowerSubsystem": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/PowerSubsystem"
+  },
+  "Sensors": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/Sensors"
+  },
+  "SerialNumber": "AAAAA-11111111",
+  "Status": {
+    "Health": "OK",
+    "HealthRollup": "OK",
+    "State": "Enabled"
+  },
+  "Thermal": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/Thermal"
+  },
+  "ThermalSubsystem": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/ThermalSubsystem"
+  },
+  "TrustedComponents": {
+    "@odata.id": "/redfish/v1/Chassis/Foo/TrustedComponents"
+  }
+}
+```
+
+### Sensors
+
+Sensors supported by tlBMC are fully owned. Sensor configurations are parsed
+from EM configs and readings are polled directly from hwmon files. There are no
+dbus calls being made to supply sensor readings in tlBMC.
+
+Note: Since tlBMC does not support all sensor types yet (only Hwmon Temp, PSU,
+and I2CFan sensors for now), tlBMC does not own sensor collection. The response
+at `/redfish/v1/Chassis/{ChassisId}/Sensors` is routed to bmcweb but a query for
+individual sensor will be routed to tlBMC if supported.
+
+An example can be seen from this config:
+
+```json
+"Exposes": [
+  {
+    "Name": "foo_external_sensor",
+    "Units": "Watts",
+    "MinValue": 6500,
+    "MaxValue": 7500,
+    "Type": "ExternalSensor"
+  },
+  {
+    "Name": "foo_psu_sensor",
+    "Address": "0x44",
+    "Bus": "11",
+    "Labels": [
+      "vout1",
+      "vout2",
+      "vout3",
+      "vout4"
+    ],
+    "vout1_Name": "foo_psu_sensor_0",
+    "vout2_Name": "foo_psu_sensor_1",
+    "vout3_Name": "foo_psu_sensor_2",
+    "vout4_Name": "foo_psu_sensor_3",
+    "Type": "ADM1266",
+    "TlbmcOwned": true
+  },
+  ...
+]
+```
+
+Since the `foo_psu_sensor` has the field `"TlbmcOwned"` and is of the supported
+type `ADM1266`, the response when any of these individual sensors is queried
+will be provided by tlBMC.
+
+## Linked Resources Not Owned
+
+For some configurations, tlBMC may detect and own the Chassis resource, but
+there may be resources configured in the EM config file that are not owned by
+tlBMC.
+
+Since the scope of tlBMC is limited to only the Chassis path at the moment it is
+possible for some Chassis to not own the resources linked in its "Links", even
+when configured in the EM config. When these properties are queried, the
+response will be populated from the traditional bmcweb path.
+
+These associated resources that are linked in response but not yet owned by
+tlBMC include:
+
+-   Storages
+-   Processors
+-   Cables
+
+An example can be seen in this config:
+
+```json
+# Assume there are two other Chassis EM configs connecting to the ports
+# Assume there is another Cable EM config with CableUpstreamConnection to Foo Cable Downstream
+{
+...
+  "Exposes": [
+    {
+      "Label": "IO0",
+      "Name": "foo Port 1",
+      "Type": "PortDownstream",
+      "User": "tlbmc"
+    },
+    {
+      "Label": "IO1",
+      "Name": "foo Port 2",
+      "Type": "PortDownstream",
+      "User": "tlbmc"
+    },
+    {
+      "Name": "Foo Cable Downstream",
+      "CableId": "foo_cable",
+      "Type": "CableDownstreamConnection",
+      "User": "tlbmc"
+    },
+    ...
+    {
+      "Name": "cpu0",
+      "Type": "Processor",
+      "User": "tlbmc"
+    },
+    {
+      "Name": "cpu1",
+      "Type": "Processor",
+      "User": "tlbmc"
+    },
+  ],
+  ...
+  "Storage":
+  {
+    "Id": "foo_storage",
+    "User": "tlbmc"
+  }
+...
+}
+```
+
+A snippet of the `Links` field resulting from querying this chassis is provided
+below. This has been annotated to show the resources that are tlBMC owned and
+not. As seen from the EM config above, several fields are configured for tlBMC
+to produce these links but tlBMC does not have ownership of the resource paths
+when queried.
+
+<pre><code class="lang-json">
+  {
+  ...
+  "Links": {
+    "Cables": [
+      {
+        "@odata.id": <del>"/redfish/v1/Cables/foo_cable"</del>
+      }
+    ],
+    "Cables@odata.count": 1,
+    "ComputerSystems": [
+      {
+        "@odata.id": "/redfish/v1/Systems/system"
+      }
+    ],
+    "Contains": [
+      {
+        "@odata.id":<ins>"/redfish/v1/Chassis/bar"</ins>
+      },
+      {
+        "@odata.id":<ins>"/redfish/v1/Chassis/baz"</ins>
+      }
+    ],
+    "Contains@odata.count": 2,
+    "ManagedBy": [
+      {
+        "@odata.id": "/redfish/v1/Managers/bmc"
+      }
+    ],
+    "Processors": [
+      {
+        "@odata.id": <del>"/redfish/v1/Systems/system/Processors/cpu0"</del>
+      },
+      {
+        "@odata.id":<del> "/redfish/v1/Systems/system/Processors/cpu1"</del>
+      }
+    ],
+    "Processors@odata.count": 2,
+    "Storage": [
+      {
+        "@odata.id": <del>"/redfish/v1/Systems/system/Storage/foo_storage"</del>
+      }
+    ],
+    "Storage@odata.count": 1
+  },
+  ...
+}
+</code></pre>
+
+## FRUs Not Detected by tlBMC but Modeled
+
+For some configurations, tlBMC does not detect the existence of the resource but
+may model it. tlBMC would have a TRUE probe for the resource i.e. Cables. In
+this case, the existence of the cable is implied by the successful detection of
+the surrounding Chassis resource and will be populated in the Cables Links of
+the associated Chassis.
+
+Here, tlBMC does not own the resource and querying the `/redfish/v1/Cables` path
+will return the traditional bmcweb response. tlBMC properties in this case exist
+only to correctly populate the associations (Links) to the `/redfish/v1/Cables`
+path in the associated resources that tlBMC does own i.e. upstream and
+downstream chassis to the cable. This is necessary for tlBMC to correctly fully
+own Chassis. In the future, when tlBMC fully owns these resources, the probe
+will become a real probe.
+
+An example can be seen from this cable config:
+
+```json
+{
+  "Exposes": [
+    {
+      "Name": "Foo Cable Downstream",
+      "CableId": "FooCable",
+      "Type": "CableUpstreamConnection",
+      "User": "tlbmc"
+    },
+    {
+      "Name": "Foo Cable Upstream",
+      "CableId": "FooCable",
+      "Type": "CableDownstreamConnection",
+      "User": "tlbmc"
+    }
+  ],
+  "Name": "NcsiCable",
+  "ProbeV2": "TRUE",
+  "ResourceType": "RESOURCE_TYPE_CABLE",
+  "Type": "Cable",
+}
+```
+
+Although tlBMC fields are required in this EM config to create the correct
+relationships when queried, tlBMC does not own `/redfish/v1/Cables/FooCable` and
+this will be served from traditional Bmcweb.