INCOMPLETE → CLARIFICATION
Missing evidence stays missing.
The packet shows what is present and what the next person must supply. A clarification request is not approval.
HUMAN CHECK
Identify the source note, owner and evidence needed before review.
EXTRA WORK → BILLING READINESS
Inspect one handoff.
Keep payment claims separate.
A field request can be clear enough to review without being an invoice or a right to payment. This fictional electrical example shows the evidence, owner and stop conditions a responsible implementation would make visible.
THE SHORT ANSWER
A field note starts the process. A person decides what is ready.
The useful first output is a reviewable packet: the request, scope revision, completion evidence, authorization evidence, pricing basis, reviewer and current state. If a required item is missing or contradictory, the record stays incomplete and names the next check.
WHAT STARTS IT
A field note, site condition or customer request that changes work after the original scope.
WHAT IS NEEDED
Scope and location, source note, completion evidence, the person who may authorize the change and the contractor’s own pricing basis.
WHO APPROVES
The contractor’s accountable project, owner or contract reviewer. Asterion’s demo does not impersonate that person.
WHEN EVIDENCE IS MISSING
Pause, request clarification and keep the exception visible. Never treat a blank field, sent message or guessed value as approval.
TRY THE FICTIONAL EXAMPLE
Follow the field request through review.
Ask for missing evidence, review the packet, reject or revise it, then change an approved scope to see why it needs another review. Every action stays in this page; nothing is invoiced or sent.
FICTIONAL ELECTRICAL EXAMPLE · LOCAL DEMONSTRATION
Extra work → billing readiness
A field note asks for 18 emergency fixtures above the ceiling after the walkthrough. Follow the evidence, clarification and human-review path without creating an invoice.
REQUEST
Add emergency fixtures above the ceiling
Brightline Electric (fictional)
Harbor Point Dental TI (fictional)
A field note asks for 18 emergency fixtures above the ceiling after the walkthrough.
CURRENT STATE
Missing information
Missing: Completion photos, Owner authorization, Work-completion note.
EVIDENCE LEDGER
What a reviewer can see
- Field note18 emergency fixtures above the ceiling; circuits tested after installation.Present in this fictional packet
- Completion photosNot supplied yetNeeds a person or source note
- Owner authorizationNot supplied yetNeeds a person or source note
- Work-completion noteNot supplied yetNeeds a person or source note
- Pricing basisSample rule: labor and material lines are reviewed against a fictional rate card.Present in this fictional packet
CONTROLLED PATH
One bounded decision at a time
The field note is not enough to prepare a reviewable packet. Ask for the missing evidence instead of guessing.
STATE PATH
Every transition has a reason.
The labels below describe the fictional demonstration’s state contract, not a universal construction process or a legal status.
READY → IN REVIEW
Submission names the reviewer.
Once the sample evidence is present, the packet moves to the responsible reviewer. The demo does not decide whether the scope is authorized.
HUMAN CHECK
Confirm scope, evidence, pricing basis and the approval boundary.
REJECTED / REVISION / STALE
Exceptions remain visible.
Rejection cannot be bypassed by repeating an approval click. A requested revision must be supplied and reviewed again. Editing approved scope clears the old approval.
HUMAN CHECK
Read back the current state before any downstream billing step.
BILLING READINESS ≠ CONTRACTUAL ENTITLEMENT
Do not turn a clean packet into a payment promise.
These states are deliberately separate because a contractor can have an internally reviewable packet while the commercial right to bill remains unresolved.
Billing readiness in this demo
A human has the sample evidence needed for the contractor’s internal review: request, scope, completion, authorization evidence, pricing basis, reviewer and current revision.
It is an operational handoff. It does not send an invoice, post a transaction or assert that a customer owes money.
Contractual right to payment
That question depends on the signed agreement, change-order or notice terms, authority, customer acceptance, applicable law, retainage and other facts outside this page.
Those facts are UNKNOWN here. A real implementation would need the contractor’s accountable owner and a separate acceptance path.
NATIVE-FIRST CHECK
Inspect the project and accounting tools you already own.
Procore and Intuit publish change-order workflows; Jobber and other products have their own plan and permission boundaries. Those official descriptions are starting points for a buyer-specific check, not proof of Asterion access or a missing feature.
01Configure
Check the existing change-order, document, approval, job-cost and invoice controls.
02Connect
Confirm the supported interface, exact account owner, scopes, identifiers and readback.
03Build
Only then consider a narrow evidence or exception view with a manual fallback.
IMPLEMENTATION DEPENDENCIES
The demo is small because the real boundary is specific.
- Product, edition/version, plan and enabled module.
- Named owner and permission to read or write.
- Scope, job, cost-code and document identifiers.
- Duplicate, stale, outage and partial-response handling.
- Acceptance cases, training, support and offboarding.
Public data boundary
Use category-level or synthetic examples in this page and review. Do not paste customer contracts, change orders, credentials, pricing schedules, payment details or private documents into a public form.
Any later provider test needs its own approved sandbox, retention, privacy and readback evidence.
THE BUSINESS SYSTEMS REVIEW
Bring one extra-work handoff.
Choose the next check.
In a complimentary 30-minute review, we can map what starts the request, what evidence exists, who approves it and which native path should be tested first. The recommendation may be configuration, a process change, a supported connection, a bounded build or no project.
What this review does not do
- Issue an invoice or send a customer message.
- Decide contract entitlement or payment.
- Authorize a provider connection.
- Turn an illustrative example into customer evidence.
Price, timing, access and acceptance follow verified scope and signed terms.
VISIBLE QUESTIONS
Answers before you book.
Need the broader contractor context? Read the commercial contractor workflow page
Does “billing ready” mean the customer must pay?
No. In this fictional example it means a human has a reviewable internal packet. Payment depends on the signed agreement, authorization, acceptance and other facts outside the demo.
What if the field note is missing photos or authorization?
Keep the record incomplete, show the missing evidence and ask the named owner for clarification. Never infer completion or approval from a message, timestamp or blank field.
Can you turn this into an automatic invoice?
Not from this page. Any invoice action would require a buyer-specific workflow, provider permissions, contract rules, acceptance tests and an authorized owner. The demo never sends or posts one.
What happens after an approved sample is edited?
The approval becomes stale and must be reviewed again. This prevents a changed scope from inheriting a decision made for an earlier revision.
Is this a customer case study?
No. Brightline Electric, Harbor Point Dental TI, the field note and every result are fictional. The demonstration proves only the bounded local behavior described here.
LET’S LOOK AT THE REAL WORK
What is your team
working around?
Bring the messy process, something new you want built, or the question of where AI fits. We will work through whether there is a sensible way to improve it.
Book a free Business Systems ReviewBook a free review
Free, 30 minutes, no commitment.
Start with the problem, not the technology.