How an Australian PMS Built AI Image Detection Into Property Inspection Software

Industry

Real Estate

Geography

Australia

Cooperation Period

8 months, 5 phases

Fig 1 – Every Property Needs a Condition Report

About the Client

The Client is an established Australian software company operating a property management system (PMS) for the residential rental market, with inspection features built into the core product. The company has been in market for more than a decade, having grown from a founder led product into a mid sized software business with paying customers in every Australian state. The Client is a recognized name in the local proptech category, sitting in the peer group of established property management platforms that agency principals name when asked which vendors they trust.

The customer base runs across a broad book of firms. Boutique real estate agencies operating a single office and a small portfolio sit at one end of the book. Mid sized property management operators running several hundred properties across metropolitan Melbourne, Sydney, Brisbane, Perth, and Adelaide sit at the other. A subset of the book is franchise networks and enterprise agencies with multi state footprints, whose head office procurement teams evaluate the Client’s product against strict data residency, security, and continuity criteria. The Client’s revenue model runs on per property SaaS pricing across the PMS surface, with the inspection features positioned as a capability that reduces the cost of servicing each property under management.

The product surface is broader than the inspection features that carried this engagement. The Client’s PMS spans trust accounting, tenancy management, maintenance workflows, an owner portal that publishes outcomes to landlords, a tenant portal, and the inspection features that are the subject of this case study. The inspection features support entry, routine, and exit inspections on a mobile capture app used in field, with a manager dashboard used by property managers back at the agency, and produce a written condition report aligned to the prescribed form under each state’s residential tenancies regulation.

Reports produced by the app enter the evidence chain at bond disputes and equivalent tribunal proceedings across Australian states. At VCAT in Victoria, NCAT in New South Wales, and their counterparts in other states, the condition report carries an evidentiary weight that shapes bond release outcomes and, occasionally, larger claims. The Client’s product therefore operates under a legal quality bar that reaches beyond internal usability. A missed defect at entry is a bond exposure at exit. A prose description that overstates a defect is a bond dispute the agency has to defend.

The product had matured into a dependable capture and workflow tool with a durable book of paying customers before this engagement began. It was the operational backbone for inspection teams at the agencies that use it, and it had earned that position over years of reliable sync, offline capture, mature integrations with the leading Australian property management systems, and a workflow the inspector’s manager could trust without supervising. That operational trust is the asset the engagement had to protect while adding native AI capability inside the same product surface.

Challenge

Two forces landed on the Client’s roadmap at the same time.

Inspector throughput was the productivity ceiling

A single inspection ran to a multi hour block per property. Photo capture at the property itself was a small fraction of that block. The majority of the block was the inspector back at a laptop, typing prose that repeated across visits and across the inspector’s own history. A three bedroom unit produced roughly the same twelve to fifteen paragraphs of prose every time, adjusted for the specific defects captured. Inspectors typed those paragraphs by hand across every inspection they ran.

The Client’s product team saw report drafting as the throughput ceiling on inspector capacity, and, downstream, on how many properties an agency could service without hiring. Every hour saved on drafting was an hour available for another visit. Every visit added revenue to the agency and utilization to the Client’s per inspector pricing. The bottleneck was that no available tool produced condition report prose to the quality bar the Client’s customers expected without an inspector rewriting most of it.

Fig 2 – The Evening Laptop Session

Competitive positioning shifted in market

A new AI native inspection platform launched in the same Australian market, purpose built to plug into established property management systems and sit on top of the incumbent’s data as a value added AI product. The competitor’s public integration list named the Client as a target platform.

The Client’s leadership read the implication clearly. Left unaddressed, the Client’s product would become the data source under the competitor’s AI product, and the inspector workflow value would migrate to the AI vendor. The economic risk was concrete. Every enterprise buyer conversation the Client had opened for years around workflow, integrations, and reliability. Those same conversations were now going to open with the buyer asking which AI vendor the Client integrated with, and the value capture was going to sit with whoever answered that question in their own name.

The response had to be a native AI capability inside the Client’s own product, delivered at production quality, before the competitor’s early access program converted to general availability. The engagement therefore carried two success conditions. Inspector time on report drafting had to fall enough to change the economics of a visit. The Client’s product had to carry a defensible AI capability in its own name.

Fig 3 – The Competitive Threat to the Client’s PMS

Why this mattered

Every AI Overview citation a competitor earned, and every enterprise buyer conversation that opened with an AI vendor question, represented value capture moving away from the Client’s own product name. With the competitor’s early access window closing, the cost of remaining unaddressed would compound with every enterprise renewal cycle.

Discovery

Before implementation began, Clixlogix ran a discovery phase to establish what the engagement was actually solving and where the design constraints came from. The phase produced a scoped delivery plan, a data audit, a legal framework brief, a state compliance map, and a risk register. Discovery established the requirements and the initial scope. It did not settle every design decision. The engagement ran as an agile delivery. Specific choices such as the placement of the room level sign off gate were refined during build iterations against measured observations from the review stream described below.

The phase separated into six pieces of work.

Remote observation of the Client’s inspection workflow

Clixlogix ran the engagement as a remote delivery. Workflow observation was built around recorded session capture and follow up video calls, and the observation stream stayed active across the whole engagement. The initial workflow understanding came from discovery. The later comparison of review gate placement drew on the same observation stream as it continued through build.

The Client’s inspectors captured live inspection sessions across metropolitan and regional properties. Each session recorded the mobile app screen, the inspector’s voice narration while walking through the property, and the follow up laptop session where the prose was actually typed. Clixlogix engineers reviewed the recordings asynchronously and held video calls with the inspectors to work through specific moments the recording did not fully explain. The rotating cohort covered a defined mix of property types, inspection types, and inspector experience levels.

The observation study ran for six months across the engagement. Over five thousand inspection sessions entered the review stream, at a peak review rate of around one thousand five hundred sessions per week. Review error observations came through two measurement channels. First, the app’s in app feedback option let inspectors flag prose or findings that missed the mark, in the moment, on the room they had just seen. Second, an evaluation chain analyzed inspector edit behavior and severity overrides across the population of reviewed sessions, so the observation stream produced quantitative signal alongside inspector self report.

The purpose was to see how inspectors actually worked, at the level of what they said out loud, what they photographed, and what they typed later at a laptop and how long it took.

The observations shaped several later decisions. Inspectors already captured far more photo detail on site than the report ended up using. The bottleneck was translating capture into prose, and every inspector Clixlogix reviewed described the same evening laptop session as the part of the job they wanted gone. Inspectors spoke about property condition in a consistent shorthand, for example “staining above the shower recess,” that mapped cleanly to a detection model’s per instance output shape once a taxonomy was defined. And inspectors caught errors in prose better when they could still see the physical room in the recording next to the prose, which foreshadowed the room level sign off gate.

Fig 4 – Remote Discovery Observation

Data audit of the Client’s inspection archive

The Client’s archive covered a database of more than a million inspection photos with inspector added field notes and free text defect tags from years of live use. Clixlogix ran a quality sample against the archive to establish what was actually in it. The audit answered three questions.

Was there enough imagery per category to train a detection model. What did the annotation shape look like across the archive. Were there systematic gaps in property type, state, lighting, or camera profile that a naive training pipeline would carry forward into the model.

The audit found that the raw archive was rich in imagery and thin on structured annotation. A detection model needs per instance bounding regions, category labels from a defined taxonomy, and severity tokens. The archive carried none of those in a training ready shape. Field notes were unstructured. Defect tags were free text and inconsistent across inspectors. A dedicated labeling program had to be scoped into the plan as a first class deliverable, and additional annotation capacity was sourced through Kaggle to accelerate the labeling pass beyond what a curated internal team could produce alone.

Legal and tribunal admissibility review

Clixlogix worked with the Client’s legal counsel to establish the evidence chain requirements a released report has to satisfy. VCAT in Victoria, NCAT in New South Wales, and their counterparts each carry specific expectations for what counts as admissible evidence of property condition. The review produced a set of hard requirements the build had to meet.

Every finding in a released report needed a traceable link back to the specific photo it described. Every sentence of prose needed an inspector’s attestation. The audit trail had to let counsel produce the source photo, the model version, and the inspector’s edit history for any finding on request. Inspector attestation on every sentence was set as a design requirement, so no AI generated content would reach a tribunal without an inspector’s identity attached to it.

The legal review was the origin of the “inspector attestation carries the legal weight” design anchor covered in the Solution section.

Competitive threat characterization

Clixlogix mapped the competitor’s product architecture from public documentation and, where the Client had permission, from a review of the competitor’s early access materials. The purpose was to establish two things. What the AI capability actually had to cover to reach parity with the competitor on enterprise sales calls. Where the depth of the technical build would show up as genuine differentiation for a buyer comparing the two.

The competitor’s stated timeline for general availability, the specific PMS platforms named as integration targets, and the shape of their sales pitch to enterprise buyers gave the Client a concrete window inside which native AI had to ship. That window shaped the phased delivery plan more than any single technical decision.

Fig 5 – Competitor Timeline and Delivery Window

State compliance mapping

Each Australian state’s prescribed condition report form differs in terminology, required fields, and inspection type handling. Clixlogix mapped the form for every state the Client operates in, producing a canonical form template per state with required fields, validation rules, and the standardized clauses required by that state. The mapping became the state compliance surface referenced in Solution section 2.

The audit found that state coverage has multiple dimensions. Terminology varies by state. Required fields vary by state. Validation rules vary by state. Consumer Affairs Victoria, for example, requires a condition report to cover cleanliness, damage, and working condition per fixture, and each of those is a required field the report cannot leave blank. A prose generation surface without a template surface enforcing field coverage would fail state validation at release time.

Options assessment and scoping decision

Discovery ended with a scoped delivery plan and an options assessment. Six approaches were assessed and rejected. One was selected. The rejections are documented in the “What we rejected and why” section below.

The chosen approach was scoped into phases with measurable milestones. Phase one covered the detection model training data pipeline, the annotation program with senior inspector reviewers, and a baseline detection model. Later phases covered the prose generation surface, the sign off gate placement study, the state compliance mapping, the residency work, and the audit trail. Each phase carried its own scope, its own acceptance criteria, and its own risk register entry with a mitigation owned before the phase started.

The scoped plan and the risk register that came out of discovery framed the agile build. Iteration boundaries carried their own scope and their own acceptance criteria. Amendments to the plan landed at iteration boundaries against the observation stream’s measured signal, not through unstructured mid stream scope creep. Every design anchor codified in the Solution section below traces back either to a finding in the discovery phase or to a build iteration observation from the review stream described above.

Solution

Clixlogix embedded a computer vision and language generation pipeline into the Client’s mobile inspection app so that photos captured during a walk through produce a draft condition report the inspector reviews, edits, and signs off. Inspectors stopped typing prose. They started reviewing prose the app produced from what they had already captured.

The design anchors

Three design anchors held fixed from the first architecture review through to production. Every subsequent decision, including every rejection covered in the section below, ties back to one of these three.

Inspector attestation carries the legal weight. Reports are legal instruments at tribunal. The AI drafts. The inspector attests. Every finding and every sentence of prose in a released report carries an inspector’s identity and timestamp, and the audit trail names which model version produced the original text and what the inspector kept or changed. The AI is a drafting assistant. The inspector is the author of record.

Findings are anchored to captured evidence. The prose does not exist independently of the photos it describes. Every generated sentence carries a reference to a specific detected region, an explicit inspector note, or a standardized clause from the prescribed form template. Sentence level traceability was a design requirement set during the legal review, and the audit trail described in Solution section 6 implements it.

The pipeline stays inside Australian jurisdiction. Every processing step runs inside AU regions. The residency boundary is enforced separately at each step, and the enforcement is documented at each step. Australian data residency is a contract obligation to the Client’s enterprise buyers and an evidence provenance obligation at tribunal, and it is enforced as such.

How the pieces fit

The build separated into six working parts. They interact in one continuous flow inside the Client’s existing mobile app.

A defect detection model reads each captured photo and produces a set of detected instances. Each instance carries a bounding region, a category label, a model confidence score, and a severity token.
A language generation surface consumes the detection output alongside the inspector’s field notes and produces prose for each room. The prose fills the sections of the prescribed condition report template for the property’s state.
A room level human sign off gate presents the AI’s finding and prose to the inspector while they are still in the room and takes the inspector’s attestation before the workflow moves on.
Regional data residency across seven processing steps keeps every photo, prompt, generated line, log, backup, and training artifact inside AU jurisdiction.
Mobile client integration wires the above into the Client’s existing inspection app as a new inspection mode, so inspectors did not have to learn a second application.
An audit trail per finding records source photos, original AI text, inspector edits, model and prompt versions, report versions, sign off type, and evidence change events for tribunal reproducibility.

The rest of this section covers each part in the detail an engineering reader needs, including the specific architecture calls to confirm before publish.

Fig 6 – Full Pipeline Architecture

1. Fine tuned defect detection model

The task shape is object detection. Each output is a set of detected instances per photo. Each instance carries its own bounding region, category label, category confidence score, and severity token. This is a distinct architecture from an image classifier, which returns whole photo labels without spatial information.

The engineering discipline behind the model belongs to the AI image detection family, and the specialization inside that family is AI defect detection calibrated for the categories that appear in Australian condition report evidence. General purpose AI image detection is not the same problem. A model trained on the internet at large will not read a subtle carpet stain against low light interior wood as the Client’s inspectors need it read. The value the Client’s model captures is the specialization, not the base architecture.

Architecture. Detection runs on an RT-DETR class transformer detector, fine tuned in PyTorch on the Client’s annotated corpus. The model produces per instance bounding regions, category labels, model confidence scores, and an urgent or not urgent severity token. A downstream fine tuned classifier reads each detected region crop and produces the reporting status for each finding, deciding whether the finding appears in the report, at what presentation priority, and routing uncertain findings to the inspector at room sign off.

Output shape and separated signals. The detection model emits three signals per instance, deliberately kept as distinct fields so the downstream components can reason about each independently.

Category label from the trained taxonomy. What is visible in the frame.
Model confidence for that category. The detector’s own certainty.
Severity on a binary scale of urgent or not urgent, calibrated at annotation time by senior inspector review.

A separate downstream fine tuned reporting model reads all three signals across the room and the whole report and produces the reporting status for each finding, which decides whether the finding appears in the report and at what presentation priority. Reporting status is not a detection model output. Maintenance action priority is derived downstream from category and severity together and surfaced in the app as a separate field. Keeping model outputs, downstream decisions, and inspector actions in different fields prevents a common failure mode where a presentation choice gets read as a physical severity claim.

The downstream reporting status, the derived maintenance priority, and any inspector actions sit in separate records that reference each detection by its identifier, so the detection model’s outputs stay auditable and immutable while the report progresses.

Fig 7 – Detection Model Output Signals

Fig 8 – Annotation Pipeline

Category taxonomy. The finding taxonomy is multi label. A single region can carry both an appearance category (staining, cracking, wear) and a component category (wall finish, floor covering, fixture, hardware). The two axes are stored as separate fields on the instance. Deduplication rules resolve overlap at inference time so a single physical finding surfaces as one entry in the report even when the model output two labels for the same region. The taxonomy definition sheet is versioned and reviewed jointly by Clixlogix and the Client’s product team.

Training archive and annotation approach. The Client’s archive covered a database of more than a million inspection photos with inspector added field notes and free text defect tags from years of live use. That raw archive by itself did not carry the annotations a detection model needs. A separate labeling pass produced the per instance bounding regions, category labels from the versioned taxonomy, and severity tokens the detection model actually trained against.

The labeling pass combined two sources of capacity. A curated internal annotation team drawn from experienced inspectors handled the categories with the highest tribunal risk and the definitional judgment calls. Additional annotation volume was sourced through Kaggle, which brought community labeling capacity to the categories where the definitional boundary was clear enough for a well briefed labeler to produce reliable output. A senior inspector reviewer set the definitional boundaries between condition impacting versus cosmetic only findings, between urgent and not urgent severity, and between adjacent categories such as staining and mold, and reviewed a rolling sample from both the internal team and the Kaggle sourced labels before they entered the training set.

A subset of the archive was annotated for training. Around 120,000 photos entered the annotated training set, contributing more than 350,000 individually labeled defect instances across the versioned taxonomy. The curated internal annotation team handled the categories with the highest tribunal risk and the definitional judgment calls. Kaggle sourced labelers covered the categories where the definitional boundary was clear enough for a well briefed external labeler to produce reliable output. A senior inspector reviewer sampled Kaggle sourced labels at a higher rate than internal team labels, and sampled labels fed a rolling agreement review. Low agreement categories triggered a taxonomy definition review before those labels entered the training set. The model test set was held out on a temporal split, so evaluation ran on photos captured after the training annotation window closed and gave an honest read on generalization to production inspections.

Training on the Client’s own annotated imagery gave the model exposure to the specific lighting, angle, and camera profile the Client’s inspectors capture in the field. It also produced a training corpus whose provenance the Client can document to enterprise buyers and to counsel if the resulting prose is challenged at a tribunal. Documented provenance was set as a design requirement by the Client’s legal counsel during discovery.

Fig 9 – Annotated Detection Output on a Real Photo

2. Language generation for prescribed form prose

State prescribed condition report forms are more than a prose surface. Each state’s form enumerates required fields (cleanliness, damage, working condition per fixture, tenant present, keys returned, meter readings), inspection type variants (entry, routine, exit), and validation constraints where a required field cannot be left blank and a severity token cannot appear without a supporting comment. The system therefore combines a versioned template surface with a generation step, not generation alone.

Model choice. Language generation runs on Qwen3-8B, self hosted on vLLM inside the AWS Sydney region. The initial delivery uses prompting on the base model with no task specific fine tuning. Fine tuning is a follow on step the roadmap can pursue if evaluation of the prompted model against the observation stream demonstrates a need. Task specialization in the initial release comes from prompt scaffolding, terminology lookup, standardized clause reuse, and template driven validation.

Prompt scaffolding. The prompt for each room’s prose fed the model a room type, the detection model’s per instance findings for the photos captured in that room, the inspector’s field notes, the prescribed form section headings for the state the property sat in, and the standardized clauses required by that state’s form. State specific vocabulary was resolved through a lookup step before prompt build time, so the model received the correct terminology as part of its prompt.

Standardized condition terminology. Where the prescribed form or industry practice defines a standardized description for a condition, for example “clean, undamaged, and in good working order,” the language model receives that exact string and reuses it verbatim. Variation across rooms is constrained to the surrounding descriptive prose. The standardized clauses are reused unchanged. Encouraging synonyms for a standardized clause would introduce inconsistent descriptions of identical conditions and create new legal risk at tribunal.

Anchoring to evidence. Supplying the model with the detection findings and inspector notes anchors the prose to the underlying evidence and reduces the rate of unsupported statements. It does not guarantee factual prose. The detection model can produce errors, and the language model can add unsupported details. The room level sign off gate covered in section 3 is the final check on any statement that reaches the report. Unsupported statement rate is tracked through the CloudWatch monitoring and custom evaluation pipeline described in the Technologies section, so the Client can see the current rate against the pre sign off threshold at any time.

Aggregation across photos. Multiple photos of one finding become one entry in the report. Aggregation runs at the room level and uses a hybrid matching approach anchored to component identifiers. Every room in the Client’s inspection app carries a component register listing the fixtures, surfaces, and features expected in that room type. Each detected instance links to a component identifier where the detection sits, and detections that share a component identifier across photos of the same room aggregate into one finding by default. Where the component identifier is not conclusive, secondary signals help, including spatial region proximity across similarly framed photos, inspector grouping through the app’s manual grouping option, and image similarity as a fallback. A finding that appears in one photo and not in another photo of the same room is not treated as contradictory evidence. A missing detection in the second photo could reflect a different viewpoint, occlusion, lighting variance, or a genuine model miss. Genuine conflicts, meaning two photos of the same component with disagreeing category or severity outputs, are surfaced to the inspector at the room sign off step for resolution.

Room revisits with new photos. When an inspector returns to a room to capture additional photos after initial sign off on that room, the workflow treats the return as a room revisit with new photos on the same inspection record. Earlier photos and prose remain in the audit trail. New photos append to the room’s photo set. The affected findings run through the AI again. Sign off on that room reverts to pending, and the inspector attests to the revised state before the report can complete. Inspection, visit, room revision, and report version are distinct concepts in the audit history. An inspection is the top level event. A visit is a physical occasion of the inspector attending the property. A room revision is an update to a room’s photo set within an inspection. A report version is a snapshot of the report at a particular point in the workflow.

Regeneration and approval. Regenerating a room’s prose is order dependent on the earlier rooms because the descriptive vocabulary constraint reads them as context. The pipeline preserves the inspector’s five most recent edits per section through a rolling edit history that the regeneration step reads before producing the new prose. An inspector’s manual override on a specific paragraph is not lost by a full report regeneration. All approvals on the affected report are invalidated after any regeneration. Every sign off must be redone. This is by design. A regenerated report is a new version, and the inspector attestation applies to the version they signed, not to a moving target.

State compliance surface. State compliance is more than terminology substitution. Each state’s prescribed form is stored as a versioned template with required fields, inspection type variants, and validation rules. Consumer Affairs Victoria, for example, requires a condition report to cover cleanliness, damage, and working condition per fixture. Defect prose is one part of that coverage, alongside cleanliness fields, working order fields, and inspection type specific sections. The template surface enforces field coverage. The generation surface fills fields that require prose. The validation surface refuses to hand a report to sign off if any required field is empty or invalid.

Human handoff for unsupported fields. A required field cannot be filled with a plausible statement the AI has no evidence to support. Where the AI lacks evidence for a required field, for example an unseen surface the inspector did not photograph, an untested fixture, or a missing meter reading, the app hands off to the inspector. The inspector fills the field manually or explicitly marks it as not observed. The AI does not produce a “clean” or “working” statement it cannot source from the evidence in the photos and notes. Room level sign off and final report validation are separate gates. A room can be signed off with a manual entry for an unsupported field. The report as a whole cannot be released until every required field across every room is either filled from evidence or explicitly marked.

3. Human sign off gate at the room level, with connectivity aware behavior

The inspector reviews every detected finding and every generated line of prose before the report is finalized. The gate sits at the room level. As the inspector walks through the property and captures photos of a room, the AI returns the finding and prose for that room to the inspector’s phone when connectivity is available. The inspector reviews it against what they are physically seeing, and either accepts, edits, or rejects it. Then they move to the next room.

Offline capture behavior. The Client’s product had always supported offline capture, and the AI workflow preserves this. When connectivity is available, AI results return to the inspector’s phone and sign off proceeds room by room. When connectivity is degraded or absent, the app queues each captured room for AI processing and marks that room’s prose as pending. Photo capture and note taking continue uninterrupted. Sign off resumes when connectivity returns.

Manual fallback. For a room where the inspector rejects the AI prose entirely, the app offers the pre AI manual entry surface as a fallback. The inspector writes the prose themselves for that room. The audit trail records the manual fallback as a distinct sign off type.

The room level placement of the gate was not the original design. The Client’s initial brief located the gate at the end of the workflow, immediately before dispatch, on the assumption that the inspector would review a completed report holistically. Clixlogix pushed the gate earlier and the reasons are covered in the Consulting Insight below.

Fig 10 – Room Level Sign Off Screen

Fig 11 – Connected vs Offline Sign Off Flow

4. Australian data residency

The Client’s enterprise buyers had two independent reasons to require Australian data residency. First, their own contracts with agency owners required AU residency for tenant photos, which include personally identifiable content in some frames. Second, evidence provenance is a design requirement the Client’s legal counsel named during discovery, and photos hosted outside Australian jurisdiction sit poorly against that requirement.

The pipeline runs its processing in AWS Sydney. Capture happens on the inspector’s phone, which sits in Australian jurisdiction because the inspector is there. Upload lands in AWS Sydney infrastructure. Detection model inference runs on a dedicated PyTorch service inside AWS Sydney. Language generation runs on vLLM serving Qwen3-8B inside AWS Sydney. Storage in Amazon S3 with versioning, logging, backups, and training artefacts are provisioned inside AWS Sydney. The specifics of each control surface are documented in an internal residency policy the Client’s enterprise buyers can request under NDA during procurement review.

Fig 12 – Australian Data Residency Map

5. Mobile client integration into the Client’s existing app

The AI pipeline was wired into the Client’s existing mobile app as a new inspection mode. Inspectors did not have to learn a second application, and agencies did not have to procure a second product. The Client owned the entire user experience from photo capture through room level sign off through delivery to the owner portal. The existing offline capture, sync, and cloud workflow surfaces of the app were preserved. The AI workflow rides on top of those surfaces.

6. Audit trail with sentence level traceability

The audit trail is designed for traceability at tribunal. It records the following fields per finding and per sentence of generated prose, so a report can be reconstructed and defended against a challenge on evidence provenance.

Sentence level references. Every generated sentence in the report carries a reference to the detected region or the explicit inspector note that produced it. Aggregated findings that fold multiple detections into one sentence carry references to every contributing detection. Standardized clauses reused verbatim from the prescribed form template carry a reference to the template version and the standardized clause identifier.
Source photo links. Every detected region carries a reference to the exact photo the detection model saw. Source photos are retrievable from the audit trail with their capture timestamps and, where available, GPS metadata.
Original AI generated text. The prose the language model produced before any inspector edit, stored verbatim.
Inspector edited text. The prose the inspector accepted, edited, or wrote as a manual fallback. Stored alongside the original for diff visibility. The 5-edit rolling history described in Solution section 2 sits within this field.
Model, prompt, template, and settings versions. The detection model version, the language model version, the language generation prompt version, the prescribed form template version, and the generation settings applied to a specific prose call. Every version is retained so the same inputs and the same settings can be replayed against the same model artefacts.
Report version history. Every save of the report is a new version. The signed off version dispatched to the owner portal is one version among many, and every earlier version remains in the audit store.
Sign off type. Whether the finding was accepted as AI drafted, inspector edited, or produced through the manual fallback. A rejected AI output that the inspector overrode is recorded distinctly from an accepted one.
Evidence change events. If the inspector adds new photos to a room after initial sign off on that room, the sign off state for that room reverts to pending, the affected findings run through the AI again, and the new outputs enter the audit trail as a separate revision. Approval does not carry across a change in the underlying evidence.

The audit trail was set as a design requirement by the Client’s legal counsel during discovery. Its purpose is traceability. For any sentence in a released report, the audit trail names which photo produced the underlying detection, which model version produced the sentence, which template version the sentence was formatted against, and what the inspector attested to. Exact reproducibility of a generated sentence is a stronger claim than traceability, and the case study describes the design as traceable.

Fig 13 – Audit Trail Record Structure

What we rejected and why

The engagement rejected six approaches that had surface appeal.

Off the shelf general vision APIs

The obvious first attempt for a team without a vision AI background is to send photos to a general purpose cloud vision API. This was rejected during scoping. General vision APIs are trained for broad category labelling and were not calibrated for the specific damage and condition taxonomies the Client’s reports require. Building a fine tuned defect detection model against the Client’s own annotated corpus was the direction the engagement took.

Pure prompt engineering on a frontier model with photo captions as input

A second appealing shortcut was to caption photos with a general vision model, then let a frontier text model produce the prose from the captions. This was rejected because the general vision model captions did not carry the finding specific detail the prose required. The text model, working from generic captions, produced generic prose. The information the Client needed the report to capture was the same information the shortcut discarded.

Ship without a human sign off gate

An early product proposal was to auto generate the full report and let the inspector spot check before send. This was rejected. Reports are used at tribunal, and a line of prose describing a finding the inspector cannot see in the photo carries a real risk to the tenant, the owner, or the agency depending on which direction the error runs. The Client’s legal counsel set inspector attestation on every sentence as a design requirement. The sign off gate is that requirement expressed in the workflow.

Sign off at the end of the report

The Client’s initial design placed the gate at the end of the report, on the assumption that inspectors would review the full document before dispatch. Clixlogix pushed back during the build iterations based on measured observations from the review stream, covered in the Consulting Insight below.

Training on public datasets or synthetic imagery

A cheaper training pipeline would have used public property inspection datasets or synthetic imagery generated by a diffusion model. Public datasets did not match the lighting, angle, and camera profile the Client’s inspectors produce in the field. Training on that data would have compromised accuracy on real inspector photos. Documented training corpus provenance was also set as a design requirement by the Client’s legal counsel during discovery. Training on the Client’s own annotated imagery, supplemented by Kaggle sourced labels the Client owned, gave the Client a provenance story it could tell counsel and enterprise buyers.

Hosted frontier model APIs

Every major frontier model provider offers a hosted API. Using one would have simplified engineering. The engagement selected private inference on Australian region infrastructure using an open weight model instead. The choice gave the Client control over regional routing, tenancy, and audit visibility across the workflow, and matched the residency design requirement described in Solution section 4.

Where the AI struggled and how we fixed it

Engineering honesty on this build. The pipeline produced acceptable output on the first end to end integration test. It did not produce publish quality output until the fixes below.

Low light interior photos

Australian rentals at inspection time frequently have curtains drawn and lights off. The initial detection model trained on well lit photos raised false positive findings on low light frames, particularly on carpet and painted walls where surface texture became indistinguishable from staining or cracks. The fix was a two part augmentation of the training set with underexposed samples and a preprocessing step in the mobile app that flagged the inspector when a photo’s exposure profile sat below a threshold. The app now suggests a retake with the room light on for photos below the threshold. Inspector retakes reduced the false positive rate on low light photos by a measured margin at evaluation time.

Overstated severity on staining that had no supporting cause evidence

The initial detection model produced urgent severity on dark stains across cases where the underlying cause was likely cosmetic, including coffee stains on carpet and shadow patches from furniture that had been moved. Assigning cause from a single photo is not something a detection model can do reliably. Staining is observable. Whether that staining reflects water ingress, spilled coffee, or a shadow requires evidence a single frame cannot supply.

Three coordinated changes fixed the overstated severity while keeping the model’s claims within what the evidence actually supports.

First, a hard negative mining pass added confirmed non condition impacting stains to the training set with explicit labels. Second, a per instance likely cause head was added to the detection model, trained to output a coarse likely cause bucket, for example water ingress consistent, cosmetic mark consistent, or insufficient evidence to distinguish. The head trained jointly with the detection head so both signals came from the same forward pass. Third, a downstream postprocessing rule read the likely cause bucket and adjusted the severity output. Findings with a cosmetic mark consistent bucket received a not urgent severity by default. Findings with insufficient evidence to distinguish surface to the inspector at room sign off with a prompt to attest to the cause based on their in room judgment.

The category label stays observable throughout. The report describes what is visible, for example “staining above the shower recess.” The report does not describe the cause as water damage unless the inspector attests to that cause based on evidence beyond the photo, for example an active leak or visible plumbing failure they can see in the room. Cosmetic stains are still reportable under the prescribed forms. The pipeline does not drop them from the report. It records them as staining with an appropriate severity, and the report presents them accordingly. Whether the finding warrants tenant recovery, cleaning at exit, or no action is a downstream decision made by the inspector, the agency, or eventually a tribunal.

Repetitive phrasing across rooms in a single report

When a defect category occurred in multiple rooms, the language model wrote near identical descriptive paragraphs for each occurrence. Reports read as if the model had a limited vocabulary, which they did.

The fix required a careful distinction. Standardized condition terminology from the prescribed form, for example “clean, undamaged, and in good working order,” had to remain verbatim across every room. Encouraging synonyms for standardized clauses would introduce inconsistent descriptions of identical conditions and create new legal risk at tribunal. The fix constrained variation to the descriptive prose surrounding the standardized clauses. The prompt for each room’s prose included a summary of the descriptive framing already used in earlier rooms of the same report, with an instruction to vary the descriptive framing across rooms while reusing the standardized clauses unchanged. Reports now read as coherent single author documents. The standardized clauses stay consistent. The descriptive prose varies naturally.

This changes generation to be order dependent across rooms. Regenerating a single room’s prose requires the earlier rooms’ descriptive vocabulary as prompt context, so any single room regeneration triggers a full report regeneration by default. Inspector edits are preserved through the 5-edit rolling history described in Solution section 2, and all approvals on the affected report are invalidated after any regeneration.

Prioritization when a frame contains multiple findings

A single frame frequently contained two findings, one high severity and one lower severity. Early prose generation described both with equal weight, and reports overstated the significance of the lower severity finding. The original working name for the issue was “ambiguous defect boundaries,” which mislabeled the problem. The problem was presentation weight, not spatial uncertainty about where each finding sat in the frame.

The fix was a presentation priority rule. Independent findings are not dropped from the report. Both remain, so no defect goes unreported at entry that could be relevant at exit. The higher severity finding leads the paragraph and is described first. The lower severity finding follows in a subordinate clause or a follow on sentence, with its severity token attached so the reader is clear on its weight. The inspector can promote the presentation priority of the lower severity finding with one tap if they judge it independently important, which flips the order in the paragraph for that photo.

State specific terminology and versioned form templates

The prescribed form in each Australian state uses different terminology for the same underlying concept. Early prose used Victorian terminology in New South Wales reports, which was factually adequate and legally awkward. The fix combined the terminology lookup step described in Solution section 2 with the versioned template surface described in the same section. Every prose generation call resolves state specific terms at prompt build time. Every generated report is validated against the versioned template for the state the property sits in before it reaches sign off. The template surface refuses a report that misses a required field for that state, so terminology accuracy and field coverage are enforced together.

Consulting Insight

The pivoting moment Clixlogix owned was the placement of the human sign off gate.

The Client’s initial brief located the gate at the end of the workflow, immediately before dispatch, on the assumption that the inspector would review a completed report holistically. During the build iterations, Clixlogix ran the gate placement question against the same observation stream that ran through the whole engagement. The comparison drew on inspector in app feedback and the downstream evaluation chain’s measurement of edit behavior and severity overrides at end of report review versus room level review. The measured difference was material. Inspectors reviewing a completed report at the end of an inspection defaulted to scanning, and skipped the deeper read. They caught obvious errors. They missed subtler ones, particularly errors that required them to remember what the room actually looked like several rooms earlier in the walkthrough.

Clixlogix pushed the gate earlier, to the room by room level, where the inspector sees the AI’s finding and prose next to the source photo before moving to the next room. The change added a small amount of friction to each inspection. It also moved the correction step closer to the captured evidence, cut the cost of correcting an error late in the workflow, and gave the Client a defensible audit trail at the room level across every inspection.

The Client’s product leadership resisted the change initially on the grounds that room level review interrupted the inspection flow. Clixlogix presented the measured observation data from the review stream. The Client accepted the change in the next iteration.

The design decision looks small on a diagram. It changed the accuracy floor of the finished reports and the Client’s confidence in publishing them under their own name.

Fig 14 – Gate Placement and Cost of Correction

Results

Within the engagement window, the platform moved from a manual, laptop bound drafting workflow to native AI condition reporting inside the field app, with measurable shifts in drafting time, inspector throughput, and enterprise retention.

50% Less Time Per Report

Average drafting and review time fell by around half per inspection, from around 120 minutes to around 60 minutes. The reduction was measured across the 5,000 plus inspection sessions in the 6 month observation window. Inspectors spent less time writing reports while retaining responsibility for final approval.

100% More Inspections Per Inspector

Completed inspections per inspector per day roughly doubled, from around three to around six on typical routine days. The comparison covered the participating agencies across the 6 month observation window and entry, routine, and exit inspection types. Teams handled more completed visits at existing headcount, without added overtime.

69% Enterprise Customers Retained

69 per cent of enterprise accounts eligible for renewal renewed during the first renewal cycle following the AI release. Customer feedback captured through the Client's account team identified native AI reporting as a renewal consideration named by buyers. These renewals covered the enterprise segment of the Client's book carrying the highest per property revenue.

6 States Reporting Coverage

The release supported validated report templates across the six Australian states of New South Wales, Victoria, Queensland, Western Australia, South Australia, and Tasmania. Coverage included entry, routine, and exit inspection types, and the required fields for each state's prescribed template. Australian Capital Territory and Northern Territory templates are on the roadmap for a subsequent release.

Fig 15 – Before and After Report Timing

What the Client does differently now

Three operational shifts that outlasted the engagement.

Inspection reports draft in field, not after hours. Inspectors leave the property with a signed off report already delivered to the owner portal. The evening laptop session is gone from the workflow.

AI capability is a first class product line, not a feature. The Client’s product roadmap now treats AI as a category owned by the product team, with its own reliability budget, monitoring, and iteration cadence. The engineering practices Clixlogix embedded during the build have transferred to internal ownership.

Legal defensibility is a design constraint from the start of every AI feature. The room level sign off gate, the audit trail per finding, the training corpus provenance, and the Australian data residency all began as legal requirements. They are now baseline requirements for anything the Client’s product team ships with AI in it. New feature scoping asks the tribunal question at the design stage.

Technologies and Tools

Area	Technology / Purpose
Defect detection	`RT-DETR`, fine tuned using `PyTorch`. Detects finding categories and bounding regions in inspection photos.
Downstream classification	Fine tuned classifier on detected region crops. Assigns urgency labels of urgent or not urgent, with uncertain findings passed to inspectors at room sign off.
Language model	`Qwen3-8B`, self hosted. Generates room level prose from structured findings and inspector notes. Initial release uses prompting.
Model serving	`vLLM` for language generation. Dedicated `PyTorch` detection service.
Backend orchestration	`Python`, `FastAPI`, `Amazon SQS`. Coordinates uploads, detection, generation, retries, and pending offline jobs.
Report validation	`Pydantic` schemas and versioned state specific templates. Validates structured output and required fields.
Database	`PostgreSQL`. Stores inspections, component identifiers, findings, approval states, and report revisions.
Photo and artefact storage	`Amazon S3` with versioning. Stores source photos, model checkpoints, templates, and report artefacts.
Mobile integration	Existing mobile framework with encrypted local storage. Preserves capture, offline queues, manual editing, and room level review.
Annotation and model tracking	Self hosted `CVAT` and `MLflow`. Manages bounding region annotation, datasets, experiments, and model versions.
Hosting and security	`AWS Sydney`, `Docker` on `EC2`, private networking, IAM and KMS. Keeps application processing and storage in configured Australian infrastructure.
Monitoring and evaluation	`CloudWatch` and a custom evaluation pipeline. Tracks latency, failures, detection quality, unsupported prose, and inspector corrections.

Services Delivered

AI Software & Application Development, Computer Vision Engineering, Language Model Integration, Mobile App Integration, Data Residency & Compliance Engineering

Team Composition

Delivery Manager, Computer Vision Engineer, ML Engineer, Backend Engineer, Mobile Integration Engineer, Data Annotation Program Lead

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

AI food logging and meal intelligence case study featured image

AI Food Identification, Calorie Estimation, and Meal Intelligence for a Premium Nutrition Coaching App

Mobile App Development Digital Engineering Generative AI & ML Beauty, Wellness & Personal Care AI

AI floor plan platform rebuilt on AWS with a routed OpenAI model portfolio

Rebuilding a Global AI Floor Plan Platform on AWS and OpenAI

Digital Engineering Devops Real Estate AI

View All Case Studies