diff --git a/xyz/openbmc_project/Error/Callout/README.md b/xyz/openbmc_project/Error/Callout/README.md
index 14a5397..0636e81 100644
--- a/xyz/openbmc_project/Error/Callout/README.md
+++ b/xyz/openbmc_project/Error/Callout/README.md
@@ -57,3 +57,32 @@
 metadata fields for both Callout.Device and Callout.IIC, but provide values
 only for Callout.Callout. That way the error handling component can still
 decipher this as an IIC callout.
+
+## Creation of a callout
+
+This section talks about creation of a callout, once callout related metadata is
+already in the journal.
+
+Taking an example of a generic device callout here, but this would be the flow
+in general :
+
+* An application commits an error that has associated callout metadata. This
+  will cause the error-log server to create a d-bus object for the error.
+
+* The error-log server will detect that callout metadata is present, will
+  extract the same and hand it over to a sub-module which will map callout
+  metadata to one or more inventory object paths, and will create an
+  association between the error object and the inventory object(s). The
+  mapping from callout metadata to inventory objects is mostly done via
+  the aid of code generated by the system MRW parsers.
+
+* Generated code : consider a case where an application wants to callout
+  an eeprom on the BMC planar, via a device path, such as
+  /sys/devices/platform/ahb/ahb:apb/1e78a000.i2c/i2c-11/i2c-11/11-0051/eeprom.
+  This would have to be mapped to the BMC planar as the FRU to be called out.
+  MRW parser(s) could be written which, for every device in the IIC subsystem,
+  can provide a corresponding inventory object path. The error-log server in
+  this case has to, by looking at the device path, determine that the device
+  is on an IIC bus, and make use of the code generated to map the device to
+  inventory objects.
+  Similar MRW parsers could be written for other device subsystems.