diff --git a/docs/api/build-logger.md b/docs/api/build-logger.md
index 7261ec9..beea3b1 100644
--- a/docs/api/build-logger.md
+++ b/docs/api/build-logger.md
@@ -33,9 +33,10 @@ pub fn build_logger(config : LoggerConfig) -> ConfiguredLogger {}
 
 Detailed rules explaining key parameters and behaviors
 
-- `build_logger(...)` constructs the runtime sink shape based on `SinkConfig` and optional queue wrapper.
+- `build_logger(...)` first constructs a base `RuntimeSink` from `config.sink`, then applies `config.queue` when present, and finally builds `Logger::new(...)` with `config.min_level`, `config.target`, and `config.timestamp`.
 - The returned logger still supports normal logging methods because `ConfiguredLogger` is `Logger[RuntimeSink]`.
 - Queue metrics and file controls remain available through forwarding helpers on the configured logger.
+- `build_application_logger(...)` only re-exports this same configured runtime logger result under the `ApplicationLogger` alias, while `build_library_logger(...)` wraps the same result in `LibraryLogger[RuntimeSink]`.
 - This API is deterministic and data-driven, making it suitable for bootstrapping from parsed config.
 
 ### How to Use
@@ -83,3 +84,5 @@ e.g.:
 
 2. Use `parse_and_build_logger(...)` when the starting point is raw JSON text.
 
+3. Use the application or library facade builders only when the boundary name or exposed surface should differ; they do not change the underlying configured runtime logger pipeline built here.
+
diff --git a/docs/api/parse-and-build-logger.md b/docs/api/parse-and-build-logger.md
index d593d02..45b09ff 100644
--- a/docs/api/parse-and-build-logger.md
+++ b/docs/api/parse-and-build-logger.md
@@ -33,9 +33,10 @@ pub fn parse_and_build_logger(input : String) -> ConfiguredLogger raise ConfigEr
 
 Detailed rules explaining key parameters and behaviors
 
-- Parsing and building are done in one step, which is useful when you do not need to inspect the intermediate `LoggerConfig`.
+- Parsing and building are done in one step by calling `parse_logger_config_text(input)` first and then passing the resulting `LoggerConfig` into `build_logger(...)`.
 - The returned `ConfiguredLogger` is just `Logger[RuntimeSink]`, so it still supports regular logging calls.
 - Queue wrapping and file control helpers remain available after config assembly.
+- `parse_and_build_application_logger(...)` only re-exports this same configured runtime logger result under the `ApplicationLogger` alias, while `parse_and_build_library_logger(...)` wraps the same result in `LibraryLogger[RuntimeSink]`.
 - Errors are surfaced as `ConfigError` rather than silent fallback.
 
 ### How to Use
@@ -86,3 +87,5 @@ e.g.:
 
 2. Prefer this API for app bootstrapping paths that read config once and then construct the runtime logger.
 
+3. Use the application or library parse/build facades only when the public name or exposed surface should differ; they do not change the configured runtime logger pipeline produced here.
+