diff --git a/REDESIGN.md b/REDESIGN.md
index dcf52f3..ed56d47 100644
--- a/REDESIGN.md
+++ b/REDESIGN.md
@@ -1235,6 +1235,23 @@ If any old FLAIM crypto/TLS-related option is required for building, it must be
 reviewed separately and kept isolated from mars-nwe provider IPC and LDAP TLS
 policy.
 
+If the FLAIM source cannot be built cleanly without old OpenSSL-facing code, the
+preferred fallback is still not to introduce a general OpenSSL/LibreSSL backend
+matrix.  A narrowly scoped CMake option may use wolfSSL's OpenSSL-compatibility
+headers only inside `third_party/libflaim`, for example:
+
+```text
+FLAIM_USE_WOLFSSL_OPENSSL_COMPAT=ON/OFF/AUTO
+```
+
+That option would be an import/portability bridge for FLAIM only.  It must not
+change the mars-nwe TLS policy, expose OpenSSL-compatible types outside the
+FLAIM/FTK build, or make LDAP/provider IPC use OpenSSL APIs.  If possible, the
+classic `FLAIM::ftk` and `FLAIM::flaim` targets should disable old TLS-facing
+code entirely.  If crypto primitives are required, prefer a small private shim in
+the FLAIM build over leaking wolfSSL/OpenSSL-compat headers into `libdirectory`,
+`nwbind`, `nwdirectory`, or future `nwnds` code.
+
 FLAIM is C++ code.  That is acceptable, but its C++ API must not leak into the
 old mars-nwe C code.  `nwbind`, future `nwnds`, `nwdirectory`, and `nwsetup`
 should use a C ABI through `include/libdirectory.h` or an equivalent internal
@@ -1274,6 +1291,54 @@ mars-nwe-specific work:
 - later `libdirectory` and libflaim-backed storage integration;
 - directory schema, bootstrap, and setup integration through `nwsetup`.
 
+The inspected `tinyldap.tar` snapshot is a small C project with one handwritten
+Makefile.  That Makefile builds several static archives and utilities, including
+ASN.1 helpers, LDAP encode/decode helpers, LDIF parsing, auth helpers, a storage
+archive, a tiny TLS archive, `tinyldap`, `tinyldap_standalone`, debug/test
+programs, index tools, ACL tools, an LDAP client, and conversion utilities.  It
+also expects libowfat-style headers/libraries and, when not using the old dietlibc
+path, links OpenSSL/crypt-style libraries for some helper code.  The CMake
+conversion should inventory those groups explicitly instead of copying the old
+`all` target wholesale.
+
+A reasonable first CMake split is:
+
+```text
+tinyldap::asn1      ASN.1 scan/format helpers
+tinyldap::ldap      LDAP PDU scan/format/search-filter helpers
+tinyldap::ldif      LDIF parsing and LDAP matching helpers
+tinyldap::auth      password/auth helpers, later routed through libdirectory
+tinyldap::storage   original mmap/flat-file storage, legacy/transition only
+tinyldap::server    original tinyldap server logic, adapted for nwdirectory
+```
+
+Optional/off-by-default targets can cover old tools such as `parse`, `addindex`,
+`dumpidx`, `idx2ldif`, `dumpacls`, `ldapclient`, `ldapdelete`, `asn1dump`,
+`mysql2ldif`, debug binaries, and tests.  mars-nwe should not require these tools
+for the normal `nwdirectory` build unless a migration/setup workflow explicitly
+needs them.
+
+The original tinyldap TLS code (`tinytls.h`, `tls_*.c`, `fmt_tls_*.c`, and
+`init_tls_context.c`) should not become the long-term TLS stack for mars-nwe.
+Keep it as reference material or disable it in the integrated build.  The
+project-facing `nwdirectory` service should use `nwtls` backed by wolfSSL for
+LDAPS/StartTLS, while the standalone tinyldap build may temporarily keep legacy
+TLS behavior only if it is isolated behind CMake options and does not leak into
+mars-nwe's TLS policy.
+
+The original storage path is also transitional.  Files such as `mstorage.*`,
+`mduptab.*`, `strstorage.*`, and the `data`/index workflow described by the
+upstream README are useful for understanding tinyldap's original database model,
+but the mars-nwe `nwdirectory` target should move toward:
+
+```text
+nwdirectory -> libdirectory -> libflaim
+```
+
+Do not make `nwbind` or future `nwnds` depend on tinyldap's flat-file storage or
+on the LDAP protocol just because the LDAP service happens to be present.  The
+shared directory API remains the internal boundary.
+
 The CMake conversion should therefore support both use cases:
 
 ```text
diff --git a/third_party/README.md b/third_party/README.md
index f5dc037..5564f64 100644
--- a/third_party/README.md
+++ b/third_party/README.md
@@ -60,6 +60,12 @@ Autotools files, but those should be treated as source inventory and build-check
 reference material.  The resulting tree should build both as a standalone library
 project and as a mars-nwe subdirectory, exposing normal CMake targets.
 
+If old FLAIM/FTK code requires OpenSSL-facing build paths, prefer disabling those
+paths for the initial classic `FLAIM::flaim` target.  If a compatibility bridge is
+unavoidable, it should be a private `third_party/libflaim` CMake option using
+wolfSSL's OpenSSL-compatible headers, not a new public OpenSSL/LibreSSL TLS
+backend for mars-nwe.
+
 The first required targets are expected to be:
 
 ```text
@@ -102,3 +108,11 @@ The planned tinyldap fork is such a component.  It should live as
 standalone under the tinyldap name and as a mars-nwe subdirectory, and it should
 later use `libdirectory`/libflaim-backed storage instead of tinyldap's original
 flat-file storage.
+
+The inspected tinyldap snapshot has one handwritten Makefile that builds ASN.1,
+LDAP, LDIF, auth, storage, tiny TLS, server, client, index, ACL, conversion, and
+test utilities.  The mars-nwe CMake conversion should split those groups into
+explicit libraries/targets instead of preserving the old monolithic `all` target.
+The original tiny TLS code should be disabled or isolated for the integrated
+`nwdirectory` target; LDAP/LDAPS/StartTLS in mars-nwe should use `nwtls` backed
+by wolfSSL.