diff --git a/clog/README.md b/clog/README.md
index 5e6b650..4c61e01 100644
--- a/clog/README.md
+++ b/clog/README.md
@@ -20,7 +20,7 @@ Many times we build unintentional colloquialisms into our log vocabulary
 and try to filter on those when looking for info. Ex: logs that say
 "recoverable error" are "the important error logs". No, none of that.
 
-If you have a set of loging that you always want to include or exclude, put
+If you have a set of logging that you always want to include or exclude, put
 a label on it.
 "How was this run configured?" -> filter clabel like /clabel_configuration/
 "What caused the process to fail?" -> filter clabel like /clabel_error_origin/
diff --git a/clog/builder.go b/clog/builder.go
index 9cdb7ae..d13c02a 100644
--- a/clog/builder.go
+++ b/clog/builder.go
@@ -40,7 +40,14 @@ func newBuilder(ctx context.Context) *builder {
 	}
 }
 
-// log actually delivers the log to the underlying logger with the given
+// log emits the log message and all attributes using the underlying logger.
+//
+// If otel is configured in clues, a duplicate log will be delivered to the
+// otel receiver.  Is this redundant?  Yes.  Would it be better served by
+// having a set of log emitters that registered by an interface so that
+// we're not coupling usage?  Also yes.  These are known design issues that
+// we can chase later.  This is all still in the early/poc stage and needs
+// additional polish to shine.
 func (b builder) log(l logLevel, msg string) {
 	cv := clues.In(b.ctx).Map()
 	zsl := b.zsl