Claim Evidence Pack for UGREEN AI NAS

• 

Inspiration

A pipe bursts under the kitchen sink. By the time the water is off, you own a small pile of problems: a soaked cabinet, a fridge that stopped, a floor that needs replacing. The insurance claim is the last thing you want to think about, and it is also the thing that decides whether any of it gets paid for.

The evidence exists. It is just never in one place. The policy is a PDF someone emailed four years ago. The receipts are half paper, half photos on a phone. The damage photos were taken in a panic, some blurry, some of the ceiling for no clear reason. So people send an incomplete file, the insurer comes back with questions, and the claim sits for weeks.

Every cloud assistant I could use for this asks me to upload the policy and photographs of the inside of my house first. That is the wrong trade. These files already live on a NAS at home, and a NAS is exactly the machine that should be doing this work.

What it does

claim-evidence-pack reads the household's own files in place and produces one claim pack, in five steps:

1. Locate the evidence. file-agent searches the agreed folder and returns real paths, grouped as policy, receipts and photos. Nothing is opened, moved or tagged.
2. Read what the policy actually covers. document-agent extracts the insured sum, the excess, the covered perils, the exclusions, the claim deadline and the insurer's own list of required documents. Each figure carries its clause text, source file and page.
3. Turn receipts into a defensible total. The same agent, using the invoice and receipt schema, with the source file recorded for every total.
4. Read the photographs. photo-agent runs text recognition on receipts that were photographed instead of scanned, and describes the damage photos: room, what is visible, any brand or model the image establishes.
5. Reconcile and write. document-agent compares the assembled totals against the insured sum and the excess. Then knowledge-agent writes the pack: incident summary, policy at a glance, coverage notes, receipt table, photo index, reconciled totals, missing evidence, and a closing line stating what the pack is not.

That last section is the real deliverable. The pack names what the insurer asked for and the pack does not contain. That list is the difference between a file that gets processed and a file that bounces.

It also refuses to guess. A receipt that cannot be read is reported as unreadable, never estimated. A policy field that is absent is reported as absent, never inferred. Confidence values from image recognition pass through unchanged. If discovery returns nothing for a group, the run says which group was empty and stops rather than quietly widening the search. And it does not decide coverage: if an exclusion looks like it applies, the Skill quotes the clause and says it appears to apply. The insurer decides.

How I built it

I started from the capability catalog rather than from an idea, because the rules are strict. A Uliya Skill is Markdown orchestration only: no scripts, no manifests, no direct CLI calls, and the parent may only delegate --target <agent> --instruction '<task>'. So the first question was not "what would be nice" but "what can the six experts actually do".

Two findings shaped the design:

• ug-document already ships extract with medical-report and receipt schemas. Reading one document is not an idea, it is one call. The value has to come from orchestration across domains.
• ug-surveillance is rich, but a demo of it depends on real camera history. A finalist gets one day of remote access to an assigned device, so a workflow that needs footage nobody can fabricate is a demo that can fail for reasons unrelated to the Skill.

That is why the chain runs across four domains and five CLIs: file discovery, document extraction, image reading, reconciliation, and a single write. Reads need no approval. The one state change goes through platform approval, and the Skill waits on it instead of working around it. Model choice stays with the child experts, so the device's local model can do the work and no document leaves the house.

Challenges I ran into

The 500-word limit is a design constraint, not a formality. Ten required questions in 500 words forced every claim to be specific. My first draft ran to 720 words, and most of what I cut was adjectives.

Writing for a checker changes how you write. The bundled static checker parses the delegate lines, so each instruction has to be single-quoted, exactly one --target and one --instruction per line, with no pipes, no command substitution and no unresolved placeholders. It also rejects any line that looks like a direct file or network call outside a delegate. That turned out to be good pressure: it is impossible to hand-wave an orchestration step, because every step has to be a real delegation to a real agent.

Deciding what "partial" means. Half the work of the failure section was deciding what happens when two of five receipts are readable. The answer, write the pack and state the gap in its own cover note, took longer than the happy path.

Accomplishments that I'm proud of

The package passes the official static check with zero errors and zero warnings on the first submission attempt, and I verified it twice: once against the source folder, once against the extracted contents of the ZIP that actually gets submitted. The same check is what rejected a direct file access line I had in an earlier draft, which is how I found out the parent Skill cannot touch paths at all.

More importantly, the Skill has a spine. Every step consumes the verified output of the previous one, and when a step comes back empty the run stops instead of improvising. For a document that decides whether someone gets paid after a flood, an honest gap is worth more than a confident guess.

What I learned

The capability catalog is the product. Once I stopped guessing at features and read the action list, the design fell out of it, and the difference between a weak idea and a strong one became visible. Weak ideas are single-capability wrappers. Strong ones are chains where each step needs the verified output of the one before it.

I also learned that a refusal is a feature. "I cannot read this receipt, and here is which one" is more useful to a person filing a claim than a plausible number that gets their claim reduced three weeks later.

What's next for Claim Evidence Pack for UGREEN AI NAS

Round 2, if selected. One day on an assigned iDX6011 Pro, running three planned validation cases: a full evidence set where the reconciled total must match a hand-computed total; two of five receipts existing only as phone photos, both of which must be recognised with their source; and a policy for a different address, which must trigger a mismatch report and a stop rather than a pack built from the wrong policy.

Then the second incident type. Floods are one loss among many. The same chain, with a different policy schema and a different photo instruction, covers burglary, fire and accidental damage. The reconciliation step does not change at all.

And a queue. One claim at a time is fine for a household. A household with three incidents, or a small landlord with several properties, needs the pack written per incident into its own folder with a shared evidence index. That is the first thing I would add after the hardware test.

Built With

• agents
• ai
• document
• extraction
• local
• markdown
• nas
• ocr
• orchestration
• ugos
• ugreen
• uliya