diff --git a/README.md b/README.md
index 81bec1f8..01aa9d0e 100644
--- a/README.md
+++ b/README.md
@@ -327,57 +327,27 @@ envrionment variables, OS specific interfaces, or the overload mechanism.
 
 ### Allocator 
 
-Objects are allocated across API/module boundaries using an ABI defined by Aurora Runtime.
-
-Such OOP design in contrast to header-everything is contingent on well-defined interface boundaries which make sense from a 
-perspective of optimizaton (primarily allocation and indirect branching) and usability.
-
-Allocations are optimized by using a known good third party library, mimalloc. In the future, it should be possible to replace the 
-standard allocator; however, for now all allocations are routed through Aurora::Memory which is backed by mi_xxxx calls.
-Mimalloc and/or other such slab and zone based allocators can and must be explored as an optimization for C++'s tendency to
-arbitrary allocate memory. This should improve the performance of reasonbly written modules with OOP in mind.
-
-Indirect branches are optimized by simply trying to design APIs that arent complete ass for humans and systems to work with.
+Aurora Runtime (would like to) provide its' own global allocator to best manage resources under one best-fit allocator.
+If the runtime is built with AuroraAlloc.cpp, every module that touches our shared pointers must also be built alongside
+AuroraAlloc.cpp. The AuList<T>, AuHashMap<K,V>, AuBST<K,V>, and AuString types are hardened against such global allocator 
+conflicts; however, shared pointers are currently dependent on a control block allocated from an unspecified allocator.
 
 ### Memory Heap
 
 Aurora provides a heap allocator for dividing up a large preallocated region of memory.
 
 Currently, we use a modified version of O(1) heap that provides a constant worst case allocation and deallocation
-of any given request. Memory is provided by AuProcess for the requested allocation, but AuMemory might be unfortunately
-hit during the initialization of a heap.
-
+of any given request.
 
 ### Shared Pointers
 
-Memory objects, including shared pointers, and the object allocation model is defined by AuROXTL. The `AuSPtr` class template
+Heap objects, including shared pointers, and the object allocation model is defined by AuROXTL. The `AuSPtr` class template
 is backed by the standard `std::shared_ptr`, extended by `#include <auROXTL/auMemoryModel.hpp>,` in the default configuration.
 
-The reason we wrap shared pointers is two folds
-1) in code that doesn't need to be fast, we can simply hack in is valid checks on assignment or use an interface with panic branches
-   to handle null access conditions. 
-2) in the future, it may be desirable to use established AuEnableSharedOnThis, AuSharedFromThis, etc idoms to migrate existing code
-   to an alternative non-std::shared_ptr backed system.
+AuSPtr<T>s allow for stage/debug build null checking to prevent hard crashing during debugging and QA.
 
-AuSPtr and friends are reducable and constructible from and from their std::shared_ptr/unique counterparts.
-
-```
-Types: 
-    AuSPtr<Type_t>
-    AuWPtr<Type_t>
-    AuUPtr<Type_t, Deleter_t>
-	
-Functions:
-    AuSPtr<T> AuMakeShared<T>(Args&& ...)
-    AuSPtr<T> AuUnsafeRaiiToShared<T>(T *)
-    AuSPtr<T> AuUnsafeRaiiToShared<T>(AuUPtr<T>) 
-
-Macros:
-    _new (pseudo no-throw new operator)
-    AuSPtr<This_T> AuSharedFromThis()
-    AuWPtr<This_T> AuWeakFromThis()
-    AuFunction<...> AuBindThis(This_t *::?, ...)
-```
+Temp AuSPtr<T>s can be crafted with AuUnsafeRaiiToShared from unique pointers and raw pointers so that C-like applications can
+access a subset of the API.
 
 Defer to [auROXTL](https://git.reece.sx/AuroraSupport/auROXTL) for more information