Add details about how the API and schema concepts relate

src/content/docs/start-here/getting-started.mdx

@@ -365,7 +365,9 @@ This inherits the access granted at at the workspace level, as defined by the do
 
 ### Checking permissions
 
-Once Kessel knows about a resource (and its relationships), you can check access by virtue of checking if the user has an expected <i>relationship</i> to the resource, as defined by your schema.
+Once Kessel knows about a resource (and its relationships), you can check access by virtue of checking if the user has an expected <i>relationship</i> to the resource, as defined by the `relation` statements your schema,
+particularly the ones referring to permissions (ie: the view, edit, and delete relations from the example above that refer to workspace permissions.) The reporter and resource types likewise come from your schema- 
+both are specified in the config.yaml in inventory and must match the corresponding `namespace` and `type` statements respectively in the KSL file describing relationships and permissions. See Configure Resources above for examples.
 
 <CodeExamples files={gettingStartedExamples} regions="check" />
 

src/examples/drive.ksl

@@ -1,5 +1,5 @@
 version 0.1
-namespace drive
+namespace drive //Define a namespace named 'drive' which is 1:1 with a Kessel reporter type
 
 import rbac
 
@@ -8,11 +8,12 @@ import rbac
 @rbac.add_permission(name:'edit_document')
 @rbac.add_permission(name:'delete_document')
 
+// Defines a resource type called 'document' which is 1:1 with the 'document' resource type associated with the 'drive' reporter type
 public type document {
     relation workspace: [ExactlyOne rbac.workspace]
 
-    // Define document permissions, 
-    // which are inherited from the workspace-level permissions
+    // Define document permissions, which are also relations.
+    // These reference the workspace-level permissions
     // that we defined above.
     relation view: workspace.view_document
     relation edit: workspace.edit_document