software • art • Spw language • semantic lattice • portable seeds • publishing surfaces
I'm Spwashi. I build software and make art. This page explains the stable creator kernel behind the site, the practice around it, and the current pressure on route grammar, proof surfaces, and helping people re-enter a thought after time has passed. It is not the final explanation; it is the current one.
The site is also a record of how I practice. I am trying to learn how I learn, then share enough of that process to discover what is useful to other people. That is why the site moves between software, art, writing, visual systems, notes, and public experiments instead of pretending those are separate lives.
A lot of the language behind that started in college. I spent time around an adult learning lab and a course called learning from text, and those experiences pushed me toward building my own language for metacognition instead of borrowing one complete vocabulary from a single discipline.
The community goal is not only expression. It is education, stabilization, and play in the same ecosystem: pages that teach without flattening, cards that help a person regain footing, and playful structures that keep experimentation attached to consequence. I want the serious parts to stay alive. I do not want the serious parts to become dead-sounding. I do not want useful language to sound embalmed.
The practical architecture is a small stable kernel surrounded by a large semantic lattice. Less formally: keep a few things stable enough that everything else can keep mutating without turning into a pile of disconnected tabs. The kernel is for continuity. The lattice is for variation.
Another way I describe it is a sharable recursive process for self-improvement: make something, inspect it, notice the abstraction, route it into another genre, and repeat until the result is useful enough to teach or strange enough to keep.
A practical version of the question is this: once I have paid attention to 1200 things, what can I actually do with that attention? I should be able to compress observations into names, seeds, routes, components, diagrams, lessons, printed objects, software modules, and rooms that other people can enter without needing the whole backstory first. If I cannot do that, then I probably just had a lot of vibes. Which, to be fair, can still matter. But I want the vibes to cash out into structure. I want them to cash out into something another person can actually use.
The bet is that attention should convert across domains. If I practice paying attention to this website, I should improve its syntax, information architecture, tone, and resilience. If I practice paying attention to software, I should design stronger tools. If I practice paying attention to craft, I should make better publishing surfaces. If I practice paying attention to services, I should make collaboration easier to begin. If I practice paying attention to play and writing, I should make systems that stay alive instead of going stale. And if I practice paying attention to library and information science and materials science, I should stage better archives, indexes, references, and stranger metaphysics for things like speech bubbles, enchantment, and CSS-driven state change. That sentence is a little wild, but I mean it. Attention should become structure. Pressure should become form.
I dropped out of college while trying to answer a question that still structures the work: why are we here, and what kind of environment helps people care? At UIUC, I founded Student Body for Meaningful Education because I wanted to treat motivation as a design problem rather than a moral failure. That question never disappeared. It moved into software, interfaces, symbolic grammar, publishing, and long-horizon learning environments.
Current pressure
Return here when you want to understand what the rest of the site is optimizing for now: route clarity, portable proof, wonder with consequences, and better re-entry paths for real people.
The about page should explain why a new surface exists before it explains every symbol in it.
The kernel is shaped by what the site had to survive lately: funding asks, study surfaces, and shared language work.
Sometimes the right revisit is not biographical. It is architectural.
Reason to wonder
If this page works, it makes the shifts across software, services, play, and the website guide feel related instead of random.
Attention is not just admiration or sensitivity. It should produce assets. After enough attention, I want stronger naming, better system boundaries, cleaner files, more useful workflows, sharper editorial judgment, clearer interfaces, and more grounded decisions about what deserves to exist.
If I pay attention to 1200 things, I should have more than impressions. I should have a lattice: repeated distinctions, better defaults, stronger taste, clearer priorities, more reliable abstractions, and a better sense of what can be combined, compressed, published, sold, taught, or turned into ritual.
Practice matters because attention compounds unevenly. Paying attention to one parser bug helps with another. Paying attention to one page layout helps with a whole family of surfaces. Paying attention to one recipe helps with timing, sequencing, hospitality, and menu design. The point is not to hoard observations. The point is to convert them into reusable structure.
My preferred conversion chain is: notice → name → compare → compress → build → publish → teach → host. That is one reason this site includes software pages, craft pages, services, recipes, play, and public notes. They are different outputs from the same discipline.
The recent direction is not to make every project equally central. The center should stay small, stable, inspectable, and teachable; the surrounding lattice can stay abundant, strange, visual, and combinatorial.
The kernel holds the durable pieces: Spw operators, route conventions, semantic component patterns, accessible HTML/CSS rules, portable seed shape, and the small set of names that should not drift every time the surface gets more imaginative.
.spw folders.The lattice is where projects cross-pollinate: spw-workbench, spw.quest, texture.website, lore.land, trope.wiki, factshift.com, RPG Wednesday, image studies, math routes, recipes, and component experiments. Each should remain local, but not isolated.
The lattice lets a visual motif become a component, a component become a lesson, a lesson become a route, a route become a printed packet, and a packet become a collectible seed.
A projection is a local view of the same deeper grammar. A homepage can project orientation. An about page can project identity and method. A lore page can project scene. A texture page can project material. A workbench can project parser state.
The public site should help a new reader understand what the work is, help a collaborator find useful entry points, help a model preserve context, and help future publishing surfaces inherit meaning without flattening the system into a portfolio blurb.
A Spwashi artifact should be able to travel: as a page section, a code file, a prompt, an SVG, a printed card, a zine fragment, a lore object, or a reusable seed package.
.spw packageA portable seed package should carry the smallest useful bundle: name, intent, operators, route anchors, visual cues, prompt cues, dependencies, and enough notes for another surface to reconstruct the local meaning.
The same seed should be able to become a card, booklet, zine page, sticker, table prop, or Boon Square. Print is not a nostalgia layer here. It is a way to make digital semantics easier to hold, gift, annotate, and revisit.
texture.website is the neighboring surface for material cues, tactile language, style contagion, and interface texture. It should help the kernel avoid becoming sterile while keeping the aesthetic inspectable.
lore.land is the narrative and publishing projection: where scenes, characters, speech bubbles, enchantment, print artifacts, and RPG Wednesday materials can become public culture instead of isolated notes.
I have spent roughly fifteen years building software, with most of my strength in frontend systems, design systems, developer tooling, content surfaces, HTML/CSS architecture, and interface language. I work best where engineering, writing, interaction design, and learning overlap.
I did not leave school because I stopped caring about education. I left because I cared enough to feel the mismatch between institutional form and lived motivation. That mismatch still matters to me. It affects how I think about note systems, learning tools, interfaces, curricula, and product design.
I grew up respecting education as a process, and part of the long thread behind this site is that school often felt more breathable than home because new subjects and new language made it easier to describe experience with peers who could share the novelty. A lot of what became my career started as experiences I could not yet bring back home intact.
That thread now has a more explicit shelf on the mental health topic.
A lot of my motivation is simple: people often have real experiences without concrete language for them yet. I designed Spw because I wanted ideas to synchronize more reliably across cultures, collaborators, and tools. I do not think the value of that work is limited to one anticipated audience. The aim is to build better naming, clearer structure, and more surfaces where a thought can test whether it is becoming shareable.
That is part of why linguistics, interface language, and operator grammar keep showing up here. They are not side interests. They are part of the bridge, and sometimes that bridge produces a real moment of recognition when someone else cares enough to wonder about meaning with you.
Lately AI has become part of that loop too. I use systems like ChatGPT to help me process the language I am already building so I can update plans for the language itself instead of starting from a blank page every time.
I like small, serious teams, strong products, readable systems, and environments where maintenance is treated as care. I care about architecture because it changes what people can sustain, inherit, extend, and teach, and because site stability, naming, and structure are never merely cosmetic.
I care about the marketplace being more socially acceptable and less ratchet. I want better pricing language, better public proof, and better engineering surfaces around creative work so people do not have to choose between dignity and legibility.
I am aiming toward senior, staff, and principal-caliber work that integrates software engineering, developer experience, design systems, knowledge workflows, publishing surfaces, educational structure, and better HTML/CSS/SVG habits for engineers who want their work to stay legible.
I build parser-driven systems, interface architecture, documentation surfaces, design systems, public websites, developer tools, and environments where plain text can accumulate more structure without becoming opaque.
The strongest expression of this right now is spw-workbench. It is the kernel candidate: a workbench for readable systems, parser/runtime/tooling integration, semantic projection, portable seeds, and structured thinking that remains inspectable.
A lot of institutions are not adjusting quickly enough to the current environment. Whatever people think of Roy Lee, I think he understands something real about where the school system is and where it is failing to adapt fast enough. That does not mean every response to that problem is wise. It does mean we need to build better structures instead of pretending the existing ones will correct themselves.
In an era of cheap generation, legibility matters more. I want systems that let people inspect what happened, recover intention, revise structure, and keep ownership over their files, reasoning, and tools. That includes authors, but it also includes engineers: I want more of us practicing plain HTML, durable CSS, and SVG as an editable medium for diagrams, characters, and reusable assets instead of treating the browser as an afterthought.
This website is part of the practice. If I practice paying attention to this site, it should become more useful, more legible, more beautiful, more technically sound, and more able to support collaboration, study, and publication.
The home page should teach how to read the ecosystem: parts of speech, components, topics, images, SVG specimens, and operator routes.
The software surface should make parser systems, operators, syntax, rendering, projection, and tooling easier to understand and extend. The nearby math routes exist partly to make those structures feel less abstract before they become implementation detail.
The craft surface should strengthen my sense of hierarchy, panels, typography, sequencing, visual rhythm, publishing structure, and SVG as a vehicle for character development and asset exploration.
The services page should convert attention into collaboration, clear scope, pricing logic, and useful contact surfaces.
The blog should help turn fragments, questions, wonder notes, and video summaries into more public and usable language, especially when those notes are moving from private authoring systems toward essays, ebooks, or lore surfaces.
The play surface should let me test interaction, symbolism, tone, live session rhythm, and narrative structures without pretending every experiment needs immediate productization. That includes RPG surfaces where scenes, textures, items, and characters can be staged, collected, and translated into later SVG or image work.
Typography should do more than look tasteful. It should tell the reader what kind of sentence they are entering and how much weight the page wants to carry.
These are some of the public references and documentation surfaces that matter most to the work.
Boonhonk is not only a visual identity. It is also a way of organizing polarity, structure, event, signal, and naming drift. It helps me think about tone, motion, hospitality, rhythm, and the relationship between practical systems and atmosphere. Lately it is also becoming a small research genre: a way to let boon, bane, bone, bonk, and honk recombine into routes, moods, captures, and character logic without flattening them into a single slogan.
Use the mixer as a readable field for disposition: hover or focus a node to preview the local force, then step weights to see how boon, bane, bone, bonk, and honk settle into a shared surface.
Arrival, benefit, invitation, reward, flow toward.
Cost, limit, friction, refusal, necessary subtraction.
Structure, scaffold, chassis, carrier, persistence.
Impact, event, interruption, comedic collision, change.
Signal, broadcast, resonance, wave, public relay.
On the RPG Wednesday surface this cluster becomes more operational. The same family can refract into Mr. BoonWAP, Mr. BaneWAP, WAPboy, Gravy Davis, Honk Bazongas, and other figures whose names tell you what kind of force is entering the room before the scene has fully explained itself.
I do not think software is the only place where structure matters. Nutrition, menu design, hospitality, pacing, atmosphere, and the circulation of care are also design problems. We can describe the ways we hope nutrition flows and then make tasty foods that embody those hopes.
I want to manage or own a restaurant or series of restaurants one day as a modality extension of boonhonk. That would let the work move from symbolic and digital surfaces into recurring physical experience: meals, rooms, rituals, timing, staff systems, repeat visitors, and public culture.
A restaurant is also a readable system. It has flows, thresholds, interfaces, menus, sequencing, maintenance, signals, and memory. It is another place where attention can be converted into structure people can actually inhabit.
The current direction is practical: make spw-workbench the small stable kernel, let the public website demonstrate the semantic lattice, and use adjacent surfaces like texture.website, spw.quest, trope.wiki, factshift.com, and lore.land as modular projections instead of disconnected experiments. Lately that also means making the math calmer and more visual, helping engineers recover stronger HTML/CSS instincts, treating SVG as a first-class vehicle for characters, diagrams, and reusable assets, and letting library-and-information-science patterns and materials-science curiosity shape the public language of the work. That is the cleaned-up version. The messier version is: I am trying to make the whole ecosystem talk to itself better, so that each surface can inherit context instead of starting from zero. Less starting over. More carrying forward.
The pacing underneath that work is not random. I think in cycles made of seasons and years, then break the cycle into 13 phases and down again into days and hours. One of the most important things I learned came from making 13 short pieces a day for a long stretch of time. The point was not volume for its own sake. It was to find a repeatable process, discover a more personal meaning, and learn what actually survives public repetition. Three videos some days, two posts other days, 13 pieces when I am really in the drill. Abstract thought on top, hard numbers underneath. Loose on the surface. Strict in the frame. That contrast matters.
When I talk about preparing a message for a lot of people quickly, I usually think less about cognition in the abstract and more about the aerodynamics of attention. Cognition matters, but attention is the first gate. If the audience has not consented to meet you on a cognitive plane yet, the communication problem is still about pacing, shape, and entry. So when something sounds obvious to me but not to other people, I do not always assume the idea is bad. Sometimes the model is fine and the entry angle is bad. Sometimes the thought is ready and the sentence is not. Sometimes you need another sentence. Sometimes you need another medium.
A lot of the work lives in an oscillation between subjectivity and objectivity. Some days I am inside the feeling, the hunch, the visual rhythm, or the sentence I cannot quite say cleanly yet. Other days I am trying to formalize the route, the component, the business logic, the operator, or the timing model. The useful thing is the motion between them, not pretending one side wins forever. Underthink and the thing stays vague. Overthink and it stops moving. So a lot of the practice is just dancing with the decision-making process long enough to keep both truth and momentum. Subjectivity generates hypotheses. Objectivity tests which ones can travel. Then the cycle turns and you do it again. That is not a flaw in the process. That is the process.
Part of that direction is personal. After being fired from a Site Stabilization Team in 2022 and then losing insurance, income, and housing, I have less patience for an engineering culture that talks about care while neglecting the actual machinery people depend on. I want tools, documentation, pricing surfaces, public notes, experiments, publishing systems, and eventually hospitality structures that carry meaning forward with more discipline and more humanity. I also want the surrounding surfaces to feel more like art without giving up their usefulness. Or said more directly: I want the systems to work, and I want them to feel like somebody cared while making them. Function, feeling, follow-through. Not just output. Not just polish.
The website is part of that discipline. So is the workbench. So are the services. So is the blog. So are recipes and food studies. So are the SVG studies and live-session asset boards. So is the wonder about how a clay figure's speech bubble might behave like a material, how CSS Houdini could eventually carry some of that story, and how routes like RPG Wednesday can become places where culture starts to hold instead of evaporating after one good night. The same underlying question keeps showing up: after enough attention, what tangible structures can I make, and how can those structures help other people live, learn, think, make, or gather better? That is the throughline, even when the surfaces look unrelated at first. Different objects, same pressure. Different routes, same question.
That is also where genre routing comes in for me. I do not mean it as a marketing label. I mean it as an emerging frontend and publishing problem: how a thought changes when it becomes a page, a short video, a card, a diagram, a game object, a sign, or a route in a design system, and how to route it on purpose instead of by accident. That is the part I think frontend people are going to care about more and more. It is about transformation costs, not just aesthetics. How much survives the crossing? Cheers. Back to the route.
Underneath all of this is a bigger claim about knowledge work: recursive learning systems are now possible in a much more public and customizable way. If someone can describe what they are trying to learn, weight the goal, and keep the structure inspectable, then the economics of learning, collaboration, and curriculum design start to shift. That is part of why I care about asynchronous and hybridized curricula too. Better structures should expand networks and distribute resources more intelligently, not just make prettier notes. I do not have every part of that model locked yet, but I think the shift is real: better learning descriptions change coordination, and better coordination changes what kinds of knowledge work become economically possible. That is one of the main reasons I keep building this in public.