pattern ladder

this seems to be my process:

1. start from your instance, the place you literally are: "reality"

2. find ground floor of abstraction: for me, it looks like "awareness", but use whatever feels irreducible, fundamental, like you could build the rest of your experiential reality from or on it

   • "experiential" is important. you can't model what you don't directly experience yourself. (note that the modeling process might change you: the edges of what "self" has experienced are only crossed by change of self. keep a really, really complete journal, and keep it out in the open. never know when or how you might need help.)

3. figure out how to rebuild the instance from the ground floor (ground up not top down, very important), developing the abstract tools for that construction

   • it's okay if the ladder you build occasionally has big steps in it, as long as your design of the ladder stays honest as you learn

   • notice when multiple paths to reality are plausible, multiple ways it could all ultimately work, ways you're not sure if the ladder is shaped like this or that or something else - keep those multiple plausibilities stable, every additional development must support all of them. some rungs are meta-abstractive: every rung that follows must support all the ways that the user might have gotten that far. this is about user-facing portability and inclusivity, and designer-facing durability and sleep-at-night-ability.

     • optimization: instead of keeping track of all plausible answers, keep track of the question, and make sure that subsequent rungs of the ladder don’t ever answer it. example: it’s cheaper for me to not be sure if I exist than to maintain all the ways I might be. yes this was a difficult position to stabilize, thank you for noticing 😅 I outsourced the question to my husband; see the take-home problem at the end

     • is this just … load-bearing apophasis? structural negative capacity? this is a weird way to arrive at a systems perspective on "we don’t talk politics at dinner"

4. use the same tools to build other stuff with other people, testing the tools in "reality", discarding the tools that break, looking for new ones

   • pattern-tools aren't things to fix. if they fail once, erase that part of the whiteboard and wait for a new tool that fills it back in. (although consider that a hole in a pattern is topologically flexible. this isn't a tabletop puzzle.)

     • doesn’t matter why they failed. a tool you didn’t understand how to use is still effectively broken.

5. gradually find more-sophisticated abstraction patterns - "sophisticated" as in provisionally complicated to accommodate new data then dispassionately refined under continuous test and application at the instance level

   • the check (not a rule but a check; you’re allowed to stretch, but pass the check before committing home to it, see below) is always that the abstraction relates clearly with all instantiations in sight

     • incompatibility is a kind of relating; interoperability is not a moral imperative

   • remember: support all the plausibilities

6. only use instances as home, not abstractions: home is a body, not a diagram. although note that meta-abstractive work allows for instantiation at a variety of levels. "subtle bodies" and all that. litmus test: a body holds you when you stop holding on. a diagram doesn't. (again, keep a journal, and keep it in the open.)

   • you can make a living (being extremely literal here) by helping people instantiate your abstractions in the context of their own instances

   • the metaphor goes lateral here: ultimately, the ladder-making is for weaving all our ladders together. like each house in the home-series is actually just a huge basket made out of disassembled ladders. ... ohhhhhh I'm describing nest-building, haha - the metaphor goes volumetric, creates a dimension that we hold open together. as long as I stay in it as instantiation, I know that (1) the ground floor will hold, and also that (2) you’re somewhere here too.

this pattern (abstract) describes the process that gave rise to this documentation (instance)

take-home problem: I've wondered about places where a body encounters a question that immediately takes the body into infinite regress when the body tries to answer that question directly. it seems that those questions must be given away, passed to another while you do other things waiting on an answer that might never come, designing a life where that’s perfectly okay. subscribe to the answer-channel instead of accumulating promises. I wonder if one could build entire realities from treating the answer as a stream and feeding the stream handle in as the irreducible input of #2? the more generative answer-channels to check, the more ticks the renderer gets per interval?

experience check: this feels like it was expensive to arrive at. not in a bad way, but in that "I had to break and rebuild my reality-modeling tools multiple times to get here" way. am I reading that right?

yeah you are reading that right haha

gosh

it cost everything

on the upside, everything seems to still be here afterwards, so

*shrug?