# Who decides whether a job needs photos? > A photo requirement is rarely a whole-business rule. One client wants proof on every visit; one contractor needs closer supervision; one job is a five-minute favour. Biloh resolves the requirement per job through four levels — job, series, client and contractor, then your tenant default — and where a client and a contractor disagree, the stricter rule wins. URL: https://biloh.com.au/docs/concepts/completion-requirements-cascade Category: Explanation | Audience: operator | Updated: 2026-07-30 Requiring a photo when a job is completed sounds like one switch. In practice it is at least four different conversations: a **client** who wants photographic proof of every visit; a **contractor** you want closer evidence from while they settle in; a **recurring service** where the photo is the deliverable; and the **one-off job** where insisting on paperwork is friction for no return. So the requirement is not a single setting. Biloh resolves it **per job, at the moment of completion**, from four levels: 1. **The job** — an explicit requirement on this one visit wins outright. 2. **The recurring series** — the contract service line the job was spawned from. 3. **The client and the contractor** — both can carry a rule; where they differ, the **stricter** applies. 4. **Your tenant default** — what happens when nothing more specific is set. The default default is deliberately permissive: completion is one tap, no photo and no note. Field speed is the point — a requirement is something you *add* where the evidence is worth the taps. ## Why the strictest rule wins rather than the most specific Levels 1 and 2 are overrides: the more specific statement replaces the general one, which is what you expect from any settings cascade. Level 3 is different, because a client and a contractor are not in a hierarchy — they are two parties to the same visit, and each may have been promised something. Consider a client whose agreement says every visit is photographed, and a contractor with no photo rule. If "most specific wins" were applied naively, whichever level the system happened to read last would decide, and a contractor-level record with no requirement could quietly cancel a commitment made to the client. That is a compliance failure disguised as a configuration nicety. So at that level the rules **merge, strictest-first**: - *require photos* — true if **either** party requires them. - *minimum photo count* — the **higher** of the two. - *require notes* — true if **either** requires them. The plain-English rule: **one party relaxing a requirement can never cancel another party's requirement.** Only an explicit decision at a more specific level — this series, or this job — can do that, and both of those are deliberate acts with an audit trail. ## One enforcement point, so every route agrees A resolution rule is only as good as the number of places that honour it. Completion can be recorded from several directions: a contractor tapping *Mark complete* in the portal, an operator recording a completion on their behalf from the office, or an AI assistant completing a job by chat over MCP. All of them funnel through **one completion write path**, and the requirement is enforced there — not in the portal's form validation. That is what makes the guarantee real: there is no route that skips the rule, because there is no second implementation of completion. A short attempt returns a clear failure naming what is missing ("2 photos required, 1 attached") rather than a silent pass. See [one write path, many callers](/docs/engineering-notes/one-write-path-many-callers) for the general pattern. Because the resolved requirement is computed server-side, the surfaces can also *show* it before anyone tries: the portal renders the exact number of photo slots the job needs and keeps the submit button disabled until they are filled, so a contractor in the field learns the rule at the start of the task instead of at the end. ## Setting it Any of the four levels is editable from the app or by asking an assistant in chat — *"require a photo on completion for that client,"* *"drop the photo requirement on tomorrow's job at the depot"* — and both routes reach the same resolution logic. The in-product help centre carries the step-by-step for each level. ## What this is an example of The cascade is one instance of a platform-wide rule: **behaviour that varies between businesses is configuration, not code.** A requirement model with four levels and a merge rule costs more to build than a single boolean, and it is the difference between a product that fits one operator's habits and one that fits an industry's contracts. ## Related - [Dispatching and triaging jobs](/docs/how-to/dispatching-and-triage) — completing, backfilling and un-completing work. - [When completing a job bills the client](/docs/concepts/when-completing-a-job-bills-the-client) — the other thing completion triggers. - [Delivery models: dispatch, self-perform, or both](/docs/concepts/delivery-models) — whose completion it is in the first place.