docs: articulate core functionality

docs/adr/001_design_principles.md

@@ -16,10 +16,11 @@ While the implementation does work, it lacks direction.
 To resolve this, I'm enforcing two new principles onto the contract of `go-cuckoo`:
 
 - **Congruency**:
-  A `go-cuckoo` table should have the same core functionality as Go's built-in map.
+  A `go-cuckoo` table should have the same core functionality as `map`.
+  By 'core', I mean `map`'s built-in syntax and functions (e.g. `range`, `m[k]`), and the `maps` package.
 
 - **Familiarity**:
-  A `go-cuckoo` table should behave similarly to Go's standard map, so users will intuitively know how to use it.
+  A `go-cuckoo` table should behave similarly to `map`, so users will intuitively know how to use it.
   In effect, its users will carry less cognitive load.
 
 These principles should _guide_ the public interface of `go-cuckoo`.