Founder Portfolio

Tamirat Lulie Wubie builds Mullusi for teams that need clearer work, review, and execution.

Mullusi is a founder-led product company building symbolic intelligence work systems that help teams turn requests into plans, approvals, records, and results.

This portfolio explains the builder, the product direction, the opportunity, and how to start a conversation.

Tamirat Lulie Wubie at a laptop
Founder

Building a practical product from first principles.

The work combines product design, systems architecture, software delivery, and research into symbolic tools for real operational work.

Public role Founder-led
Product route Mullu visible
Runtime boundary AwaitingEvidence

Portfolio claims stay tied to public routes, status pages, and proof boundaries.

Product Direction

A work system for planning, review, and reliable records.

The first route is Mullu: a product path for teams that want proposed actions reviewed before important work moves forward.

Current public pages explain the product, status, security, contact, and proof routes. Deeper API, dashboard, sandbox, and metrics routes open when they are ready for users.

Role Founder, architect, contributor, and current solo developer.
Offer Planning, review, approval, records, and controlled work execution in one product direction.
Current route Mullu is the first public product path; deeper services remain staged until support is ready.
Product Path

What visitors should understand in the first minute.

Mullusi is not another loose chat or ticket layer. The public product path shows how a request becomes a proposed action, gets reviewed, and leaves an evidence record.

  1. 01 Request

    Capture what someone wants to do and why it matters.

  2. 02 Review

    Expose constraints, owners, risk, and approval needs before motion.

  3. 03 Approve

    Keep human authority visible while the system preserves structure.

  4. 04 Record

    Leave a trace that can be inspected, challenged, or rolled back.

Evidence state Website route visible; product runtime witness remains AwaitingEvidence.
Guide Layer

The eye helper should guide before it inspects.

Public visitors need orientation first. Technical reviewers need proof boundaries. Builder inspection stays available as an advanced mode.

Public Guide Explain the current section and next useful action.

For first-time visitors, the helper should summarize what they are reading and point to Mullu, proof, or contact without exposing DOM packets.

Proof Lens Show claim boundary, route status, and evidence state.

For evaluators, partners, and reviewers, the helper should separate published routes from reserved surfaces and clarify what is verified.

Builder Inspect Keep DOM metadata, target packets, and receipts behind advanced use.

For development and audit work, the existing inspector remains valuable, but it should not be the default public explanation layer.

Opportunity

The opportunity is the gap between chat, tickets, docs, and execution.

Teams need systems that can prepare work, show intent, route review, and keep records without adding another loose channel.

ProductMullu starts with planning, review, approvals, and records for controlled work.
TechnologySymbolic intelligence, structured state, validation, and visible status for work that needs trust.
VisionA public work layer where people keep authority while software handles structure, trace, and repeatability.
Contact

Start with product, research, or partnership questions.

Use the public contact route or the listed mailboxes for focused conversation about Mullusi, Mullu, research, support, or collaboration.

Interface guidance follows the selected language. Helper metadata, mailbox addresses, route identifiers, and evidence enums remain unchanged.