Built examples · reviewed September 9, 2026

The process behind the software.

Three evidence-led examples: the problem, what exists, the review path, and the limits. Diagrams explain the builds; they are not screenshots or measured client results.

Working build for Digital Refraction’s own lead review

A request-to-review queue

Notes, example links, drafts, and approval decisions become difficult to inspect when they live in different places.

Context and notes → draft and checks → human approval → next action
Process diagram based on documented work. Not a product screenshot or client-result graphic.

What exists

A built review dashboard holds lead records, public context, example links, draft checks, and approval status together. The input is a prepared record; the next consequential action remains a human decision.

What this demonstrates

A single review path can make the basis for a decision visible before action.

Limitations

This is not proof of automatic inbound capture, end-to-end delivery, increased sales, or a deployed local-trades client system.

Read the plain-language walkthrough →

Working calculation tool

Document review and voucher calculation

Re-entering document details and checking time-and-rate calculations creates repeated work and opportunities for mistakes.

Capture document → review fields → check calculation → prepare export
Process diagram based on documented work. Not a product screenshot or client-result graphic.

What exists

The tool supports document capture, editable values, time-and-rate calculations, and output preparation. Defined rule cases have regression checks; source comparison and final approval remain human tasks.

What this demonstrates

Source documents can feed a reviewable calculation workflow without treating extracted text as unquestionable fact.

Limitations

Extraction can be wrong, and exceptional terms require review. No universal calculation accuracy, payroll certification, or measured time saving is claimed.

Read the plain-language walkthrough →

Working prototype with a sample-data demonstration

Daily administration and approval

Daily time entry, corrections, approval status, and reporting handoff need to fit the working day and different review roles.

Enter the workday → submit for review → return or approve → reporting handoff (development goal)
Process diagram based on documented work. Not a product screenshot or client-result graphic.

What exists

A working prototype includes time records, signatures, review states, and a role-specific overview. The demonstration uses fictional records. Wider reporting/export completion and production rollout remain distinct work.

What this demonstrates

Custom software can model the actual entry, exception, and approval path while keeping future scope separate.

Limitations

The demonstrated review flow is not evidence of a completed rollout or verified accounting export. No customer adoption or measured outcome is claimed.

Read the plain-language walkthrough →

What would a useful first step look like for you?

Bring the handoff, queue, or document process that keeps slowing the team down.

Talk through a workflow