Prototyping invoice discovery without claiming a live integration

I built an Invoice Automation prototype around two related tasks: find partner invoices and remind partners when the expected invoice is missing. The useful engineering work was translating those tasks into explicit configuration, states, injected dependencies and reviewable logs.

The prototype boundary matters as much as the workflow.

The inspected finder route supplies generated email results, a simple text extractor, a synthetic Drive result and a no-op processed-thread marker. The reminder route supplies an email sender that returns true. Configuration and logs live in module-level arrays. I do not present those adapters as a deployed Gmail, PDF-extraction, Drive or outbound-email integration.

Give each partner a search and matching contract

The finder engine accepts search, extraction, storage and thread-labeling dependencies. Smart queries add a recent-mail window and exclude a processed label; exact queries pass through the configured expression. Active partner configurations determine which searches run.

I made the campaign-match rule explicit.

The inspected implementation normalizes case and separators, then performs substring matching against extracted text. Attachments qualify by PDF MIME type or filename extension. Existing filenames can be skipped through an injected set. After a storage result, the engine creates a master-log entry and updates the partner's found state. A thread is marked processed if at least one attachment was saved.

These are understandable rules, but their limits are concrete. Filename identity is weaker than content or stable provider identity. The current route passes an empty existing-log set for every run, so the engine's duplicate check is not backed by prior run history there. A thread-level processed label after one successful attachment could also hide another attachment that failed in that same thread.

Inspect the system diagram

Open full-size SVG →Horizontal version →

Simulation still changes the prototype's state

The reminder engine checks its calendar conditions and sends initial or follow-up reminders through an injected function. Test mode skips that transport call. It still stamps the relevant sent timestamp, changes the mapper's status and records a log marked as test mode.

That is a simulation of progression, not a read-only preview.

I would explain the distinction before someone uses it for operations. The inspected engine also awaits the sender but does not use its returned boolean to decide whether to stamp success. A thrown error is caught; a resolved false value has a different effect. Real transport adapters would need an explicit acceptance contract and corresponding state transition.

Module-local arrays make configuration and log review easy during a prototype session. They do not provide durable recovery across restarts or coordination across server instances. Search, file storage, thread labeling and log persistence also remain separate operations; there is no shared transaction with the providers.

My production plan would introduce durable provider IDs, attachment-level checkpoints, explicit transport outcomes, persistent configuration and logs, and separate preview from simulated progression. Those are next steps, not completed features in this case study.

Invented prototype walkthrough

1. Configure fictional partner Harbor Supply with a campaign reference and a destination folder placeholder.
2. Inject two invented email attachments: one matching invoice and one unrelated PDF.
3. Show the campaign normalization, the matching decision and separate saved, skipped and error records.
4. Run the reminder engine in test mode. Show that transport is skipped while the prototype's status and timestamp advance.
5. Reconstruct a resolved-false transport response and discuss the missing acceptance check.
6. Restart the prototype state and explain why module arrays do not establish durable history.

This uses injected fixtures and reconstructed branches. It is not a live invoice import or an email sent to a partner.

Contribution and result

The authored change contains the application, domain engines, configuration and run routes. The authored change aligns its interface with shared design tokens. These records support a working prototype and integration-shaped interfaces. They do not support a production automation, invoices recovered, time saved or reminders delivered.

I would use this as a product-to-system design discussion. The story shows that I can map an operator's task into states and boundaries, and that I can distinguish a convincing prototype from a durable service.