Engineering notes

The decisions behind
the interface.

Two short implementation notes from the portfolio. They describe design choices, not independently measured business outcomes.

A relevance score is not a decision.

In TenderBot, a notice is useful only in the context of a company: eligibility, geography, delivery constraints and negative signals. An unexplained score makes the reviewer depend on a black box.

The workflow therefore keeps the company profile, reasons, revisions, feedback and source documents connected. Document analysis adds context; a person retains the participation decision. This also makes a disagreement actionable: correct the profile or inspect the evidence, rather than simply rerun a prompt.

A suitable evaluation would use a dated set of representative notices and reviewer decisions, with explicit definitions of relevant, unsuitable and uncertain. No accuracy percentage is claimed here without that measurement.

Inspect the TenderBot case

Payment, access and delivery are different states.

The paid report platform connects a website and Telegram to one commerce backend. Payment verification, entitlement and report generation are separate boundaries; a screen saying “paid” is not the source of truth.

Repeated provider callbacks should not produce repeated entitlements. A report job should survive a temporary delivery failure. The customer-facing state must distinguish payment, processing and access to the finished artifact.

Acceptance checks should include a repeated payment event, a failed generation attempt and a delivery retry. These are testable recovery scenarios, not promises that an external payment provider can never fail.

Inspect the paid report case