diff --git a/docs/command-logging.md b/docs/command-logging.md
index 2afcd1e..59e3174 100644
--- a/docs/command-logging.md
+++ b/docs/command-logging.md
@@ -21,6 +21,14 @@
 !!! important
     Commands can not be reused. They can be scheduled multiple times, but they can not have multiple parents.
 
+## Customization
+
+By default, commands will be logged using their class name. Specifically, `class.getSimpleName()`.
+
+If you want to have a command with a different name you can call `command.setBasicName()`.
+
+Reasons for this may be if you have a command that is context dependant and want to easily differentiate between its use cases.
+
 ## How Command Logging works
 
 !!! note
@@ -104,3 +112,28 @@ The `CommandLogger` works by subscribing to some of the events of WPILib's `Comm
 3. `onCommandInterupt(Consumer<Command> action)`
 
 On each of these events, we store the recorded state in a queue which then gets logged every tick.
+
+## Advanced Use cases
+
+Sometimes it is convenient to create and schedule and command within another command.
+
+Take the following example, where we create a command that goes to a position.
+
+```java
+public void initalize(){
+  LoggableCommand command = new GoToPoseCommand(drivetrain);
+  command.schedule();
+}
+```
+
+This will work but when we are looking for the command in AdvantageScope, it may make more sense to see the `GoToPoseCommand` listed under the command who called it.
+
+This can be done by calling `command.setParent(this)`.
+
+```java
+public void initalize(){
+  LoggableCommand command = new GoToPoseCommand(drivetrain);
+  command.setParent(this);
+  command.schedule();
+}
+```
diff --git a/docs/subsystem-logging.md b/docs/subsystem-logging.md
index da84eee..c09c259 100644
--- a/docs/subsystem-logging.md
+++ b/docs/subsystem-logging.md
@@ -184,11 +184,19 @@ Starting off simple, all the `InputProvider` classes do is provide a common inte
 
 Inputs contain the actual fields that are being logged.
 
+Similar to Command Logging, we want to maintain a tree like structure for our Inputs. To do this, each Inputs extends `FolderLoggableInputs` which in turn extends `LoggableInputs`.
+
+`FolderLoggableInputs` takes in a folder that is describes the hardware it is logging. You can name this what ever you want but I would recommend just putting the class name of the subsystem.
+
+!!!note
+    Logged folder can have subfolders separated by a /
+
 There are two different ways of creating `LoggableInputs`.
 
 The *Legacy* method involves extending `FolderLoggableInputs` and declaring the properties by hand and how they are written and read from the log.
 
 The second method is using one of the prebuilt input classes with customizable parameters that can be selected using the corresponding Builder.
+
 If using [method 2](#method-2) you can use one of the prebuilt `FolderInputs` classes.
 
 ``` mermaid
@@ -228,6 +236,18 @@ class PidMotorInputs {
 
 Every `FolderInputs` (and subclasses) are in charge of logging the values that were selected using the builder.
 
+So far it has been pretty simple, but how do we get to the different customizable inputs like `NeoPidMotorInputs` you may ask.
+
+There is another class that all the customizable Input classes extend, and that is `FolderInputs` (poorly named).
+
+All `FolderInputs` does is declare an abstract method called `process(InputProvider inputProvider)`.
+
+Ohhhh, I hear you say so that is where the `InputProvider` comes into play!
+
+The process method will then be called by IO Interfaces, with the corresponding `InputProvider`.
+
+As mentioned in [How to log a Subsystem](#how-to-log-a-subsystem), the two `FolderInputs` implementations are `MotorInputs` and `PidMotorInputs`.
+
 ### InputBuilders
 
 Each InputBuilder is contains methods that set a flag indicating if the user wants to log a specific value. For example `MotorInputBuilder#encoderPosition` sets a boolean to `true` indicating that the `encoderPosition` should be logged.