As of 2026-08-04, this article describes the Egan Forge dashboard and publishing repair represented by the source files listed at the end. It does not claim that every proposal can be completed automatically. It describes the contract for distinguishing execution, delegation, failure, and missing evidence.
The original goal for the Egan Forge CEO dashboard was practical: let one owner review a company decision from a phone, approve or reject it, and let the relevant agentic process carry the decision through. The owner should not need to stay attached to a development workstation just to keep normal operations moving.
The old approval path did not meet that goal. It could change a proposal's status to approved, but a changed status was too easy to mistake for a changed system. Some handlers wrote a directive for a later cycle and reported completion. Other dashboard panels converted an unreachable source into a zero. Together, those behaviors created approval theater: the interface looked decisive even when the underlying outcome was unknown.
The contract: a decision is not an outcome
We now separate the proposal lifecycle into states with different meanings:
| State | What it proves |
|---|---|
| Proposed | An agent has asked the CEO for a decision. |
| Rejected or deferred | The CEO made a durable decision, but no implementation should run. |
| Delegated | The exact approved directive was persisted or queued for an addressed process. The final outcome is still open. |
| Completed | A handler performed the work and returned a concrete verification result. |
| Failed | The action or its required persistence step failed. |
That distinction sounds small, but it changes how the company can be operated. A queue write is valuable; it is not completion. A service restart command is action; it is not verified until the service and its post-restart evidence are read. A dashboard should preserve those differences because the CEO's next decision depends on them.
Legacy approved records with no execution evidence are no longer bulk-marked complete. They return to the review queue. This makes unfinished work visible instead of manufacturing a clean history.
Review once, authorize exactly that effect
Opening a proposal now requests a read-only effect preview before the decision button is enabled. The preview classifies the handler, target, risk level, expected effects, and verification requirement. It also includes a deterministic hash of the current proposal and execution plan.
When the CEO confirms, the server recomputes that hash. If the proposal or classified effect changed after the preview, approval fails and the current version must be reviewed again. This closes a subtle race: an approval cannot silently apply to different text or a different handler than the one displayed on the phone.
The confirmation burden scales with consequence:
- Ordinary review, investigation, and standing-directive decisions use a normal confirmation after the effect preview.
- Operational changes capable of restarting or deploying production software require an explicit operational authorization phrase.
- Capital and trading-risk changes require a capital-risk phrase plus an acknowledgment of the classified effect.
This is not designed to keep the CEO at a desk. It is designed so frequent, reversible decisions stay quick while rare actions with a larger blast radius get one deliberate pause. Rejection and deferral remain lightweight.
One important correction came directly from applying this rule. A performance-remediation handler previously invented concrete trading thresholds downstream of approval. Those thresholds were not necessarily present in the reviewed proposal. The repaired handler persists the exact CEO-reviewed directive and delegates that text. It may not add its own position-sizing or confidence policy after the fact.
Approval now starts work
For an approved proposal, the dashboard calls the classified delegation handler immediately. Handlers can restart and verify a known service, inspect signal logs, persist an exact directive, queue implementation work, or invoke the existing innovation implementation process. The result is written back to the proposal record with the handler, action, verification, and notes.
This creates the mobile operating loop we actually wanted:
- An agent presents a proposal with its evidence.
- The CEO reviews the concrete effect on a phone.
- Confirmation authorizes that exact effect.
- The handler acts now or delegates to a named next-cycle consumer.
- The dashboard reports completed, delegated, or failed based on what happened.
The interface does not call a delegated item complete just because the handoff succeeded. That open state is useful. It gives future automation a clear work queue and gives the CEO a clear exception queue without requiring supervision of every intermediate step.
Telegram still supports rejection and deferral, but approval now routes to the authenticated dashboard. A Telegram button cannot display the complete effect preview or collect the stronger authorization required for disruptive actions. The dashboard remains mobile-friendly, so this trades an unsafe one-tap mutation for a short review flow without turning the process back into desktop-only work.
The same truth rule applies to metrics
Decision automation is only as good as the state it reads. The dashboard's executive snapshot now wraps each headline metric with its scope, basis or time window, source, sampled time, freshness, and reconciliation state.
Live trading, paper trading, custody balances, product revenue, subscriber receipts, and API costs are separate scopes. They are not added together because they happen to be denominated in dollars. Today, trailing thirty days, and calendar month-to-date are separate cost windows. An unavailable source returns an unknown value rather than a zero.
The marketing and SEO views follow the same rule. A sitemap shows which URLs the company declares for discovery; it does not prove that Google indexed them. Search indexing remains unknown until Search Console is connected. Missing newsletter or social-channel ledgers remain unknown rather than implying that the measured count is zero.
Customer promises use the same operating evidence
The public site now derives product availability from the canonical catalog. As of 2026-08-04, twelve catalog products are available and one is withheld because its hosted application is not deliverable. The withheld product is excluded from the sitemap and its page cannot take payment.
The paid lifetime bundle, affiliate program, operations bundle, and prompt pack had stronger promises than their fulfillment evidence supported. Their purchase or recruitment routes are now paused or redirected until payment, identity, entitlement, delivery, refund, support, and audit evidence pass end to end. The main site points commercial intent toward the fixed-scope automation service while keeping available individual tools usable.
That decision is not anti-revenue. A payment that creates an entitlement or support obligation the system cannot reliably fulfill is not healthy revenue. The goal is a closed loop: promise, payment, delivery, support, measurement, and renewal or completion.
Publishing without restarting the content mill
The blog is publishing again through a narrower contract. Older generated posts remain preserved as a historical archive but are excluded from the index, feed, and sitemap until their claims and links are reviewed. New drafts must have a unique slug, substantive structure, safe links, and source notes for volatile company metrics.
The content agent may create a validated draft and open a dedicated content branch. It may not push generated writing directly to the production branch. That keeps the agent useful without asking the CEO to watch every generation cycle or letting unreviewed claims become company statements.
The broader engineering principle is the same across approvals, metrics, storefronts, and publishing: autonomy should remove supervision work, not remove evidence. A good agentic process earns latitude by making its scope and outcome easier to inspect.
Source basis
The implementation described here is grounded in the repository's proposal preview and action routes in core/dashboard/api.py, delegation planner and handlers in core/master/tools/proposal_delegation.py, metric contract in core/dashboard/truth_contract.py, executive dashboard in frontends/dashboard/src/app/page.tsx, product lifecycle registry in frontends/site/lib/product-catalog.ts, and publishing validator in core/tools/blog_publishing.py.
If your company needs a similarly bounded automation loop, start with the workflow and the evidence required to call it complete—not with the number of agents. Explore Egan Forge automation services or read the public transparency notes.