Hearth & Code

A studio, not a black box

The studio is organized around the work itself: a question, a source horizon, a constrained artifact and a return. AI can participate in every stage, but it does not erase ownership. A source retains its author; a reviewer retains judgment; a person retains the decision to act.

This matters because useful work accumulates. A good result should carry enough context that someone can inspect it, revise it or continue it later without recreating the entire conversation.

The technique in practice: Choose one artifact. Give it a name, a source and an owner. Before adding a new tool or capability, ask who will review the result and what counts as a useful return. That small discipline keeps a system from becoming a collection of unowned outputs.

The public posture

Public pages use clear labels for public orientation, teaching example, candidate design and review-only system. Those labels are not decorative. They prevent an interesting experiment from being mistaken for a deployed service or a completed claim.

Where detailed source material is private, the public layer uses a synthesized example that demonstrates the method while leaving private records, identities and operating detail where they belong.

Claim boundary example: On this page, every statement about method or practice is a description of a working approach, not a declaration of universal efficacy. The claim-boundary panel at the bottom of each page names what this page does not assert.

The areas of practice

The work crosses agentic engineering, software architecture, knowledge synthesis, prompt craft, research design and creative systems. These are not collapsed into one generic AI capability. Each asks for its own inputs, evidence, constraints and checks.

The root orientation map keeps those areas visible as separate rooms, then shows the shared method that allows them to connect without losing their meaning.

Concrete distinction: A prompt technique and a Rust type pattern may both use "input → transformation → output" as a frame, but they operate at different levels with different failure modes. The prompt might hallucinate; the Rust compiler rejects. They are both "checks" in different senses. The methodology page traces each meaning separately.

What a return contains

A useful return names the thing made, the source or assumption it depended on, the check that was performed and the next bounded question. It also names the limit: what has not been tested, authorized, released or verified.

That small discipline makes the work easier to trust for the right reason. It gives a reader a way to distinguish an artifact from its promise.

Formulation sketch: Let A be an artifact, S the set of sources it depends on, C the set of checks passed, U the set of checks not performed, and Q the next actionable question. A return R is the tuple (A, S, C, U, Q). Its utility is that a downstream reader can update S or add C without reconstructing the original reasoning. This is a pedagogical formulation, not a formal ESS record; see the methodology page for a fuller treatment.

Choosing a starting point

New readers may find the methodology page the most direct entry, since it defines the working cycle that connects all the practice areas. Readers interested in concrete runnable examples can start with Fieldcraft. Those evaluating the architectural approach should read the engineering page first.

Guiding question: If you could get one thing right about your interaction with an AI tool, what would it be? If the answer is "know what it's actually doing" → start with Fieldcraft. If it's "know what I'm committing to" → start with methodology. If it's "see how all this fits together" → start with work & studio.

How the site is organized

The root dashboard (this page) is the orientation surface. Below it, seven detail pages correspond to practice areas. Fieldcraft is a separate library of 32 runnable field notes. The GitHub repository contains the full source, build scripts and visual system — public and inspectable like everything else here.

The pages share a navigation bar, typographic scale, color system and responsive layout. Each has a distinct visual device (compass, weave, loop, catalog, evidence, stack or board) that matches the information structure of that page.

Creative practice as a discipline

Creative work — visual direction, narrative, interactive media, music — benefits from the same discipline as engineering work: a source, a bounded task, a check and a return. The difference is in the kinds of evidence a check can produce.

In creative work, a check often evaluates against an aesthetic brief, a contrast criterion or a directional question rather than a logical predicate. That does not make the check less real; it makes the claim limit more important. A good creative return says what was explored, what was set aside and what direction is proposed next.

Worked example: A visual direction brief includes reference sources, a contrast formula (check that two design options differ by a measurable criterion such as WCAG contrast ratio) and an explicit boundary: 'this direction explores the warm palette; it does not resolve the mobile layout.' FC-011 demonstrates checking design contrast with the WCAG formula.

Technique: Vary one creative parameter at a time. When exploring color, keep the layout fixed. When exploring layout, keep the typography fixed. This makes the creative decision traceable: 'we chose option B because it improved readability under the contrast criterion, while A did not.' FC-010 demonstrates varying one creative parameter at a time.

The practice areas in depth

Each practice area — agentic engineering, knowledge work, software architecture, prompt craft, research design, creative systems — has its own input types, evidence standards, failure modes, and return shapes. Collapsing them into one generic AI capability loses the specificity that makes each useful.

Practical distinction: In agentic engineering, failure means an unplanned side effect or an unhandled lifecycle state. In creative work, failure means a direction that does not serve the brief. Both are valid checks, but they answer different questions. A methodology that works for one may not transfer to the other without adjustment.

Worked example: An agentic system that routes a user request to a tool must decide: is this a research question (→ heuresis), a code change (→ faber), or a design decision (→ forma)? The routing logic depends on distinguishing these cases by input type, not by generic capability. The orientation pages provide this distinction for each area.

Source-aware collaboration patterns

Working with AI systems requires preserving authorship, evidence lineage, and decision boundaries across every exchange. A source-aware collaboration treats each interaction as a bounded artifact with a known owner, known sources, and an explicit return.

Pattern: the collaboration contract. Before starting, declare: (1) what the AI may access, (2) what it may produce, (3) who reviews the result, and (4) what constitutes a useful return. This prevents the collaboration from broadening through adjacency — the AI's awareness of related work does not grant it scope to act on that awareness.

Worked example: Scott and Virgil agree: Virgil may read declared Hub sources, produce candidates in the Hub's project home, and verify build output. Virgil may not read secrets, commit to Git, call providers, or represent Scott externally. Every output is a candidate awaiting review. This contract is written and versioned.

The return as a durable artifact

Every significant interaction with an AI tool should produce a return — a compact artifact that names what was done, what sources were used, what checks passed, what limits remain, and what the next actionable question is. The return survives the conversation. It makes the work useful after the chat is closed.

Anatomy of a useful return: Goal (one sentence), Current state (what exists now), Last verified change (the exact mutation or check), Evidence (what was observed), Risks (what could go wrong), Open questions (what is not yet known), Next action (the smallest physically doable next step), Safe stop (how to clean up if work is interrupted).

Counterexample to avoid: A status update that says 'progress continues, no blockers.' This communicates nothing useful about what was done, what was learned, or what would change the approach. A return should enable a future reader to resume without recreating the lost context.

Handling uncertainty in practice

Uncertainty is not a problem to eliminate — it is a feature to name. A methodology for handling uncertainty includes: (1) distinguishing what is known from what is inferred, (2) stating confidence explicitly rather than hiding it in fluent prose, (3) defining what evidence would change the assessment, and (4) holding decisions that do not yet have sufficient support.

Worked example: A research synthesis returns: 'Source A reports measurement X under condition Y. Source B reports measurement not-X under condition Y. Both studies have N=30 and similar methodology. The contradiction cannot be resolved from available evidence. Next action: check whether the measurement instruments differ. If they do, the apparent contradiction may be an artifact of different definitions. If they do not, the contradiction is genuine and should be surfaced as a minority conclusion.' Here uncertainty is labeled, not erased.

Verification as a practice

Verification is a named check against a stated predicate. It does not happen by passing tests, deploying code, or reaching consensus. Each verification event records: what was checked, what predicate was tested, what result was obtained, what was not tested, and who or what performed the check.

The verification boundary: A passing test suite verifies that the code behaves as specified under the tested conditions. It does not verify that the specification matches the user's need, that the code is secure, or that it will work in production. Each of those is a separate verification with its own predicate, check, and evidence.

Counterexample: A continuous integration pipeline that runs tests and deploys automatically may create the impression that verified code is reaching production. CI pipelines verify build integrity and test coverage. They do not verify fitness for purpose, safety under adversarial input, or alignment with user intent. The distinction matters when a deployed system causes harm.