You cannot price what is behind the wall.
You can make sure it never goes unrecorded.

Straight answer, there is no latent conditions register and no unknowns log in VIABUILD. The mechanism for a discovery is the variation, and the honest version of this is that software cannot tell you what is behind the wall, it can only make sure that what you find becomes a priced, approved, recorded change rather than a conversation nobody wrote down. What the variation workflow does give you is speed and evidence, which is what a discovery actually needs. The change is priced from real takeoff or budget lines rather than typed from scratch, each line carrying where it came from. The client sees a summary written in plain language that the editor refuses to send unless it reconciles to the price. They approve by typing their name on a single-use link. And the variation itself records whether the change affects the programme and by how many days, so a delay caused by a discovery is captured on the document that created it rather than argued about later.

Two ways, depending on what the sum is for. Where the provisional sum is something the client decides, a bathroom fit-out, tiling, joinery, it is carried as a selection with a provisional sum allowance at the figure written into the contract, inclusive of GST as contracts state it. The client is shown options, chooses on a link with no login, and the difference against the allowance is calculated and shown as an over or under, with an alert to you naming the selection and the amount the moment the choice lands. Where the provisional sum is work you will scope rather than the client, it is budgeted as a cost code line like anything else and reconciled through a variation when the real number is known. What the system does not do is convert an over-allowance choice into a variation by itself, because whether an over-run is charged, absorbed or renegotiated is a commercial decision about a client you have to keep working alongside for another four months. The system makes sure you know, in time to make it.

No, and this is worth stating plainly rather than implying otherwise. There is no contingency register and no drawdown ledger tracking a contingency pool being consumed across a job. Contingency in VIABUILD is budgeted as a cost code line the same as any other allowance, and it is spent by coding costs to it, so you can see what has been drawn against it in the cost position but you are not being given a purpose-built contingency mechanism. If contingency drawdown reporting is central to how you price and defend a renovation, that is a genuine gap and it should be part of your decision now rather than a discovery later. The reasoning behind carrying contingency properly, independent of any software, is in the reference on estimating contingency.

That is the workflow this product invested most heavily in, because a change a fortnight over an eight month job is thirty documents that each have to be priced, sent, approved, costed and claimed. Lines are pulled from takeoff measurements, budget lines or catalogue products rather than typed, each stamped with its source and linked back to the budget line behind it. Omitted scope comes across as negative quantities credited at cost with markup set to zero, so you never refund margin on work you removed, which on a renovation swapping scope repeatedly is the difference between holding a margin and quietly funding the client changes. The client-facing summary is composed separately from your internal build-up, so you are not handing over a marked-up cost breakdown to be argued line by line, and the editor will not send a variation whose client rows do not reconcile to the sell amount. Every variation across every job also appears in one pipeline, so nothing sits in draft for three weeks because it belonged to a job nobody opened.

Three things move together, and they are stamped individually so a failure part way through resumes rather than half applying. The contract sum increases by the variation total, with the approved variations figure updating alongside it, so the original contract sum plus approved variations always equals the current contract sum. The variation lines land on the latest locked budget grouped by cost code, updating the line if the code already exists and adding one if it does not, with an entry written to the budget audit log. And the variation becomes claimable, appearing in the claims screen ready to raise. Approval is terminal by design, so a variation cannot be silently reversed after the client has agreed to it. If the client declines, it goes back to draft keeping its number, so a revised and resent variation is version two of the same change rather than a new one.

A link, on a phone, with no app to download and no password to remember. That is a deliberate design decision rather than a limitation, because homeowners do not adopt project portals and the ones who do use them once. Through that link they see their selections and choose from options, and they receive and sign variations by typing their name, on a single-use link that expires after thirty days. What they do not see is your internal cost build-up, because the client-facing rows on a variation are composed separately from the priced lines underneath. On your side, the record of the day comes from the site rather than being reconstructed on Friday. Daily logs and photos are captured on a phone with one hand free, and document revisions are kept as a chain rather than overwritten, so the drawing a decision was made against still exists exactly as it was. In an occupied house, where the client saw the work happen, that record is what a disagreement is settled from.

A weekly cash forecast across the whole organisation rather than job by job, which is the right unit when you are running eight small jobs instead of two large ones. It is built from your progress claims, schedule phases and tasks, supplier invoices, purchase orders and recurring items, with a client payment lag applied and BAS and GST included, and it states its assumptions on screen rather than hiding them, including that it assumes no retention is withheld. Every figure is deterministic arithmetic over records you can open, computed at the moment you ask rather than stored or batched overnight. No model produces a number anywhere in it, which is why we do not describe it as AI forecasting. What that gives a renovation builder specifically is the ability to see the week where three jobs all have suppliers falling due and only one claim landing, far enough ahead to move an order or bring a claim forward.

No latent conditions register and no unknowns log, as above. No contingency drawdown mechanism beyond a cost code line. No retention handling. No preset stage templates, so your claim stages and percentages are set up per contract. Cost-plus terms are recorded on the contract, meaning margin percentage, billing cycle and an optional maximum budget, but a cost-plus claim is not generated automatically from the actual costs incurred in a period, so if most of your renovation work is cost plus, raise that early. No payroll, and no labour hours costed to jobs from timesheets. It is not built for civil or commercial work. And Oryn is not a chatbot. It reads plans and supplier invoices at the point paperwork enters the system, extracts line items, matches them to orders and suggests cost codes from the vocabulary of your own history, cites the document and page every value came from, and never commits anything touching money or a contract without a person confirming it.