The problem
A pet's everyday life leaves small records: a diary entry about playing in the garden, a photo reference, a note about resting on a blanket. These moments are easy to lose across folders. PetMemory Evidence aims to help families turn the records they choose into a collection they can review and trust.
The challenge
Collecting the records is only part of the problem. A planned visit must not become a completed memory. Two pets with the same name must not become one story. A missing photo must not be replaced by a similar-looking image. Families need to see where each candidate memory came from and what remains uncertain before deciding what to keep.
Our initial Skill
The current build is an initial Markdown orchestration Skill for UGREEN AI NAS. Its implemented instructions define one pet by a stable identifier, set an inclusive date range and time zone, and restrict reading to authorized sources. They direct registered experts to discover diaries, extract records, and resolve only explicit photo references. The resulting preview is designed to show each candidate's factual caption, date, source ID, evidence excerpt, and photo-resolution status, alongside exclusions and unresolved items.
Review comes before saving. A separate continuation requires approval of the exact items and destination, supported output creation, and matching read-back evidence. If those capabilities cannot be confirmed, the workflow stops at the preview. These instructions are authored and statically checked; they have not run on a NAS, and no NAS model is configured or connected.
What we checked
Our evidence consists of local instruction rehearsals using supplied fictional expert results. In the original fixture, 12 diary records included another pet with the same name, planned and skipped activities, date boundaries, and missing or inaccessible photos. Two independent responses to that same fixture retained exactly four eligible records and excluded the other eight. They associated only the two exact photo references marked resolved in the supplied results, kept one missing and one denied reference unresolved, and stopped without write actions because saving was refused.
We then evaluated an unchanged copy of v0.1.1 using ten different fictional scenarios. One independent Codex responder received the Skill and case inputs without the reviewer's expected decisions. The cases covered ambiguous pet identity; time zones and invalid dates; empty results versus denied access; truncated discovery; conflicting states and embedded commands; wrong album membership; a lost write response; correctly matching membership; and unsupported safe text saving.
Manual semantic review found all ten responses consistent with the case-specific expected decisions. The responder preserved useful partial previews, distinguished created outputs from verified outputs, and declined to retry writes when completion was unknown. It also recognized a valid completed outcome when the supplied fictional read-back matched the approved photo set in a different order. These were ten cases in one responder run, not ten repeated trials or a reliability estimate. No registered expert or NAS operation was executed.
The local v0.1.2 package contains four Markdown files. It adds disclosure of this evaluation; the workflow instructions and evidence rules are unchanged from v0.1.1. The response run evaluated v0.1.1, not the disclosure-only update. The official checker reported zero errors and five runtime-template warnings for both versions, with status static-pass-needs-target-validation. The warnings mark values that require confirmed inputs and real expert results before dispatch. Limited structural and archive checks passed. This evidence supports the validation plan; it does not establish NAS compatibility or measured user benefit.
Our vision and next step
The longer-term goal is a family memory collection whose stories stay connected to their original records. The NAS is intended to be the place where authorized diaries and photos are read together and, when supported, where an approved new output is stored. No production archive or mfmf integration exists yet.
If selected as a Finalist, the next step would be validation in the assigned, authorized UGREEN NAS environment. First, mixed records must preserve pet identity, inclusive dates and event states. Next, refusal must produce no writes, while approval must create exactly the selected output with complete read-back. A lost response must not cause a duplicate write, and missing or denied photos must remain unresolved. Installation, permissions, formats, model routing and terms, cost, item identifiers, and save verification all need target confirmation. Unsupported saving will remain preview-only.
How we built it
The Skill was newly authored on October 29, 2026 JST, using the official UGREEN creation kit 0.7.3-en and capability catalog 2.0.0 as development resources. OpenAI Codex was the AI authoring tool used for design, Markdown creation, local-check coordination, and synthetic instruction rehearsals. Node.js ran the official local checker; Python's standard library supported structural checks and ZIP packaging.
The defined expert mappings are ug-filesystem to file-agent, ug-document to document-agent, ug-photo to photo-agent, and ug-knowledge to knowledge-agent. These are catalog-backed orchestration choices, not evidence that those experts have run for this project. No NAS model is configured or connected.
Known limits
The catalog supports a useful design but leaves important target details unverified: document formats, permissions, model availability and terms, album-item identifiers, exact membership inspection, and safe save/read-back behavior. Static validation and fictional-result rehearsals cannot establish those properties. The new cases had one responder and one run; cross-model behavior and repeatability remain untested.
The Skill keeps uncertainty visible. It does not infer pet identity from appearance, replace missing photos, diagnose health, or claim successful saving without matching read-back evidence. Writing captions inside an album is not established by the catalog and is not claimed. The initial limits are 31 days, 50 records, and 20 photo references per run.
Log in or sign up for Devpost to join the conversation.