[Metadata: crossposted from https://tsvibt.blogspot.com/2022/12/possibilizing-vs-actualizing.html. First completed December 31, 2022. This essay is more like research notes than exposition, so context may be missing, the use of terms may change across essays, and the text might be revised later; only the versions at tsvibt.blogspot.com are definitely up to date.]
Some behavior seems like it's just making things possible, without actually doing much of anything, while other behavior seems to actually do something. Is there a principled, or a useful, distinction between possibilizing and actualizing? Is it possible to possibilize a large effect on the world without actualizing large effects on the world?
It's not clear whether this is a real distinction, but to me it's a very intuitive and intuitively salient idea (because possibilizing seems safer than actualizing), so I'd like to have a better analysis or dissolution of it.
Possibilizing is making something possible for an agent to do. That is, it's setting the stage, preparing, unlocking, satisfying the preconditions, gathering the needed resources and tools, gaining the necessary understanding and skill and components and information, getting agents on board, making the plans, opening the way. "Possible" is cognate with "potent", "power", and "hospital". Other possible words: enabling, feasibilizing, empowering.
Actualizing is (an agent) actually doing something, making something happen, achieving a goal, affecting something, having impact, delivering a payload. Other possible words: realizing, implementing, exerting.
Taking a step forward along a path possibilizes the next step, and contributes to possibilizing further steps; and it actualizes itself, a forward movement of the walker. In this example, it does seem like there's much distinction between possibilizing and actualizing: what's being possibilized (subsequent steps) is the same sort of thing as the possibilizing (the current step), and they interact in a straightforward way. Intuitively, this is mere progress, not possibilizing, so the above definition of possibilizing is incomplete.
Speed cubers first look at the Rubik's cube, then put it down, and then pick it up and turn its faces. Before they pick it up the second time, in their head they're possibilizing solving the cube by figuring out the sequence of moves. Before that, they had to understand how to solve the cube and train that skill, which was also possibilizing solving the cube. The order can't be switched: you can't turn the faces so the cube is in a solved state, and then, after that, figure out for the first time what sequence of turns would solve the cube. But you can "think with the cube", trying out moves to see what happens, sometimes backtracking, which blurs the distinction.
To build a complicated house, you look at the site where you'll build it, then you leave and elsewhere you think and draw pictures, and then later you come back and build the house.
A lot of engineering tasks are solved straightforwardly. But engineering tasks that push the envelope require the engineers to recurse up to more abstract thinking (e.g. "first-principles thinking"), removing all but the most necessary assumptions/constraints, finding an abstract design that satisfies the abstract constraints, and then constructing a new concrete, detailed design in a way that's beholden to the abstract design.
Coming up with a word possibilizes the expression of some thoughts.
Coming up with a concept possibilizes making good predictions and finding good designs. If you don't know about chromatic dispersion, you'll be confused about why your lenses produce images with weird color-dependent blurring, and you'll have trouble knowing, without physically testing, how much chromatic dispersion a novel lens design will have.
Proof of concept. When I want to write a computer program to do something cool but a bit complicated, and I'm not sure it'll be feasible given my time and ability, I start with tinkering around (sometimes mentally) to find a minimal implementation of the least obviously feasible part of the whole program. I don't start the program at the beginning (for example, I don't start writing helper functions to process user input). When the most uncertain parts have some janky, minimal implementation, then "lightning strikes": there's a pathway for the voltage to travel through the previously maybe-infeasible seeming parts, all the way through the system, to actually do anything at all. It's not a minimum viable product or a proof of value, because it doesn't necessarily do anything cool; it's just a proof of the feasibility of the concept. E.g. if I want to make a website, and I've never made a website before, I don't start writing HTML, I check if I even know how to make a website at all, such that someone could put a URL into a web browser and then see something that looks the way it does because of code I wrote.
Possibilizing vs. actualizing might not be a suitable distinction, but if it is, what might that distinction be? Some possibilities: