Dowelify

The knowledge dowel for physical work and AI. Every part of the work, aligned.

Comment

Inspiration

My career has largely been in production and R&D for plasma-based physical vapor deposition systems, working as a process engineer. In that environment, knowledge cannot merely sound convincing. It must remain connected to the actual machine, the applicable manual or procedure, the instrument that produced a measurement, the person who performed the work, and the physical outcome.

That experience shaped how I see AI.

AI is extraordinarily capable, but many people do not trust it—and often for good reason. They have encountered hallucinations, generic recommendations, synthetic content, and confident answers disconnected from the particular object or problem in front of them. The deeper problem is not simply that AI sometimes gives a wrong answer. It is that most AI systems do not preserve a reliable relationship between what the model says and what the physical world has actually established.

I believe there is a way to make AI more honest and useful: give it a durable structure in which evidence, uncertainty, decisions, actions, and outcomes remain distinct and traceable.

That is why I built Dowelify.

This need exists at very different scales. It applies to an engineer working from a plasma-deposition system manual and an SOP, a technician recording instrument measurements, and a homeowner trying to repair a toilet without receiving pages of generic, irrelevant advice. The equipment and expertise differ, but the underlying problem is the same: the knowledge needed to complete physical work is fragmented, and the next person often has to begin again.

The research foundation

My research into reachability provided the deeper conceptual foundation. I have been studying what happens when an intelligent system loses the ability to reach its intended goal—when the path between its current state and a viable outcome collapses.

The question behind that work is:

What can still happen from here?

Dowelify brings that question into physical work. It helps a person understand where the Job currently stands, what evidence supports that understanding, what possibilities remain open, what actions might close other possibilities, and what still needs to be established in the real world.

Coding has systems such as GitHub, Cursor, Claude Code, and Codex. They help software work retain context, preserve changes, examine alternatives, and move toward a goal. Physical work does not yet have a broadly adopted equivalent. Its knowledge remains scattered among conversations, phones, PDFs, measurements, forms, and individual memory.

Dowelify is my attempt to build that missing bridge: a knowledge dowel connecting physical reality with its evolving AI representation while keeping both aligned to the same Job.

What Dowelify does

Dowelify turns a physical problem into a continuing work record instead of a disposable chatbot answer.

A person can begin in ordinary language or with a photograph. Dowelify keeps the conversation, people, evidence, manuals, possible Paths, measurements, decisions, work records, costs, outcomes, and follow-up attached to one durable Job.

The system deliberately distinguishes:

  • what someone reported;
  • what a source says;
  • what a person or instrument measured;
  • what an AI inferred or proposed;
  • what a person decided;
  • what work was actually performed; and
  • what was accepted, released, or observed afterward.

That separation matters. An AI can help interpret and organize physical work, but it cannot truthfully claim that it touched the machine, performed the repair, or verified the result.

Dowelify also includes an invitation-only remote Model Context Protocol service. Its current eight-tool surface lets authorized AI clients retrieve governed measurement knowledge through structurally read-only access. Credentials, storage internals, raw samples, unauthorized Jobs, mutation authority, and physical release authority remain outside the model-visible boundary.

How I built it

The application uses a Python service, append-only PostgreSQL records, checksum-locked migrations, a browser-based JavaScript workspace, and Railway deployment. Its measurement contracts and MCP boundaries use closed JSON Schemas, strict validation, principal-scoped discovery, authorization before tool-name resolution, OAuth with PKCE, rate limiting, and append-preserved audit records.

Before the Build Week submission window, Dowelify was an early production-hosted pilot with foundational repair reasoning, authenticated Case persistence, an initial conversation runtime, and one narrow guided repair flow.

During Build Week, I extended it into a connected physical-work system with durable Jobs, attributed participation, assignments, Paths, records, work entries, costs, aftercare, a typed measurement evidence backbone, reviewed Research and Visual-reference foundations, and a separately deployed read-only MCP staging service.

I built Dowelify primarily with Codex and GPT-5.6. I directed the product, physical-authority, security, and release decisions. Codex and GPT-5.6 accelerated the architecture, Python and JavaScript implementation, database migrations, JSON Schemas, test suites, adversarial security review, MCP and OAuth design, branch reconciliation, CI diagnosis, documentation, and exact deployment evidence.

The collaboration was iterative rather than a single prompt. I challenged model assumptions, rejected overclaims, selected the durable Job and knowledge-dowel architecture, and required honest unavailable states whenever evidence or infrastructure was missing. Some bounded work received Claude assistance, which I disclose rather than erase, but Codex with GPT-5.6 was the primary environment for the project’s conception, implementation, review, integration, and submission assembly.

The model used inside a deployed chatbot is a separate runtime choice; it is not evidence of which model built the repository.

Challenges

The hardest challenge was not generating plausible repair language. It was defining what an AI may honestly know and do in the physical world.

Dowelify had to remain useful while keeping evidence, inference, authority, action, and outcome separate. The same problem appeared in MCP: access needed to be useful without exposing identity, credentials, storage details, raw physical data, unrelated records, or mutation authority.

A second challenge was continuity. Conversation, measurements, Paths, documents, sources, people, performed work, and aftercare all had to remain attached to the same Job without collapsing into one undifferentiated stream.

A third challenge was integrating many concurrent Build Week workstreams without claiming that code was deployed merely because it existed. The repository uses exact-commit CI, controlled migrations, append-preserved development records, explicit live-versus-candidate distinctions, and release gates.

Accomplishments

I am proud that Dowelify now includes:

  • a real production-hosted, conversation-first pilot with durable Jobs and Paths;
  • an exact-head green application candidate connecting Measurement, Research, Visual references, Conversation, Paths, and Sources;
  • a live, invitation-only remote MCP staging service with eight read-only tools;
  • authorization that happens before tool-name resolution and conceals unauthorized Cases;
  • closed schemas and safe result envelopes that exclude credentials, identity, storage details, and raw-data leakage; and
  • honest unavailable states for capabilities that are not production-ready.

The live application and green candidate are described separately. The newer Measurement, Research, and Visual tranche is tested but is not represented as deployed until production health proves it. The MCP remains a bounded staging service, not a public connector or a claim of field validation.

What I learned

AI can help in the physical world, but its most important contribution may be continuity rather than autonomy.

A useful system does not need to pretend that the model touched the machine. It needs to make evidence legible, preserve uncertainty, propose bounded next checks, retain human decisions, and allow another person or authorized AI to resume from a trustworthy record.

I also learned that provenance is not administrative overhead; it is a product feature. People should be able to see which observation, source, measurement, decision, or performed action supports the current understanding—and which important facts remain unknown.

Trust does not come from making AI sound more certain. It comes from giving people a clear relationship between the model’s representation and the physical work.

What’s next

The next stage is repeated real-world use: completing genuine physical measurement Jobs, expanding beyond the first guided repair family, connecting rights-cleared technical knowledge, testing controlled instrument inputs, strengthening judge and client onboarding, and recording outcomes and aftercare across many Jobs.

The long-term goal is not to give AI physical authority it does not possess. It is to make AI useful enough, honest enough, and accountable enough that people can confidently use it to understand and continue physical work.

The knowledge dowel for physical work and AI. Every part of the work, aligned.

Built With

Share this project:

Updates