Dowelify

Note: This analysis is based entirely on the self-reported project description provided by the caller. No external verification, revenue data, customer names, traction metrics, or independent sources are available.

The description states that Dowelify is a system for physical work and AI that:

• Turns a physical problem into a continuing work record instead of a disposable chatbot answer.
• Keeps conversation, people, evidence, manuals, Paths, measurements, decisions, work records, costs, outcomes, and follow-up attached to one durable Job.
• Distinguishes between:
  • 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.

It also includes an invitation-only remote Model Context Protocol (MCP) service, which allows authorized AI clients to retrieve governed measurement knowledge through structurally read-only access.

Claim: The system is built using Python, JavaScript, PostgreSQL, Docker, GitHub Actions, and OpenAI APIs.

Evidence: Self-reported in the project write-up.

Inference: The system appears to be a prototype or early-stage product focused on traceability and structured knowledge management for physical tasks.

Not evidenced: No actual deployed version, user feedback, or real-world usage data.

The author positions Dowelify as:

• A solution to the problem of AI giving answers disconnected from physical reality.
• An attempt to make AI more honest and useful by maintaining a reliable relationship between model outputs and physical outcomes.
• A bridge between software tools like GitHub or Codex and physical work environments.

It is described as:

• Not about making AI autonomous, but about helping it be useful, honest, and accountable in physical contexts.
• Focused on continuity rather than autonomy.
• A tool that makes provenance a product feature, not administrative overhead.

Claim: Dowelify aims to align AI with the physical world through structured knowledge representation.

Evidence: Self-reported in the project write-up.

Inference: The positioning reflects a niche focus on physical work environments where trust and traceability are critical.

Not evidenced: No market positioning, competitive differentiation, or target audience validation beyond the author’s personal experience.

The description states that Dowelify addresses:

• Engineers working from manuals or SOPs;
• Technicians recording instrument measurements;
• Homeowners trying to repair a toilet without generic advice.

It suggests the system applies across different scales of physical work, from industrial R&D to DIY tasks.

Claim: The target is anyone doing physical work who needs reliable knowledge alignment.

Evidence: Self-reported in the project write-up.

Inference: The ICP likely includes technical professionals and DIY users with access to physical tools and documentation.

Not evidenced: No defined customer segments, personas, or usage patterns beyond the author’s own context.

No business model or pricing information is provided in the description.

Claim: None stated.

Evidence: Not evidenced.

Inference: Given that this is a hackathon submission and no revenue or monetization strategy is mentioned, it appears to be an experimental project without a commercial plan.

Not evidenced: No indication of monetization, licensing, or pricing models.

The system uses:

• Python backend
• JavaScript frontend
• PostgreSQL database
• Docker containers
• GitHub Actions for CI/CD
• OAuth 2.0 with PKCE
• JSON schemas for validation
• MCP (Model Context Protocol) staging service
• Append-only records and checksum-locked migrations
• Rate limiting, authorization before tool-name resolution

Claim: The system is built using modern development practices including security controls, structured data models, and CI/CD pipelines.

Evidence: Self-reported in the project write-up.

Inference: The technical stack suggests a focus on secure, traceable, and scalable architecture for handling physical work records.

Not evidenced: No deployment details beyond Railway or staging environments; no performance metrics or scalability claims.

The author reports:

• An early production-hosted pilot with foundational repair reasoning
• A conversation-first pilot with durable Jobs and Paths
• A live, invitation-only remote MCP staging service
• Exact-commit CI, controlled migrations, and append-preserved development records

Claim: Dowelify has progressed from a prototype to a functional system with some real-world use cases.

Evidence: Self-reported in the project write-up.

Inference: The system shows signs of iterative development and early adoption within a limited scope.

Not evidenced: No customer data, user feedback, or measurable usage statistics; no public-facing product or commercial traction.

The author references:

• Coding systems such as GitHub, Cursor, Claude Code, and Codex
• The lack of a broadly adopted equivalent for physical work

Claim: There is no widely accepted system for managing physical work in the same way that software tools manage code.

Evidence: Self-reported in the project write-up.

Inference: Dowelify may be positioned to address a gap in physical work knowledge management, similar to how Git addresses version control for code.

Not evidenced: No competitive analysis, existing products, or market positioning beyond the author’s own claims.

• Lack of external validation: All information is self-reported and unverified.
• No commercial traction: No evidence of revenue, customers, or adoption beyond the author’s own work.
• Limited scope: The system appears to be a proof-of-concept or early-stage prototype.
• Unclear path to monetization: No business model or pricing strategy described.
• Single-person team: Only one founder is mentioned, which may limit execution capacity.
• Invitation-only MCP service: Indicates limited accessibility and potential scalability issues.

Claim: The system lacks commercial viability or traction.

Evidence: Not evidenced.

Inference: Based on the lack of any real-world usage or monetization strategy, Dowelify is likely in an exploratory phase.

Not evidenced: No risk assessment or mitigation strategies provided.

1. What specific physical work environments have you tested Dowelify with?
2. How do you plan to scale beyond the current invitation-only MCP service?
3. Are there any real-world users or pilot programs outside of your own development?
4. What is the timeline for moving from a prototype to a commercial product?
5. How do you intend to monetize this system, if at all?
6. What are the key assumptions about user behavior and adoption that underpin your design?
7. Can you provide examples of how the system handles uncertainty or incomplete data?
8. How does Dowelify integrate with existing physical work tools or systems?