This is a submission for Weekend Challenge: Dog Days Edition.
AI disclosure: I used Codex extensively to implement, test and review this project, and to draft this post. I verified the public build, the live Snowflake execution and every numerical claim below.
What I Built
When a dog goes missing, the words used by owners and shelters rarely line up perfectly. "Gray" may arrive as "silver." "Border Collie mix" may be recorded as "Border Collie." A nearby intake can be easy to miss.
A weak resemblance can also create false hope.
I built Bark Back Home, a missing-dog search desk that compares a structured report with Austin Animal Center's public intake data. It returns a short ranked list, explains every point in the score and refuses to select a candidate when evidence is weak, conflicting or too close to another result.
The three sample missing-dog reports are fictional. The app does not collect owner names, contact details, photos or exact home addresses. Shelter candidates come from public records, but a ranked result is never presented as an identification.
Bark Back Home can say which public record deserves human review. It cannot say that the shelter dog is yours.
Demo
The hosted demo is deliberately fixture-only. It never receives a Snowflake key and cannot create warehouse spend. Its header and every result label say Offline fixture.
The live acceptance run exercised the same application API against Snowflake through a local, least-privilege service. The main report was Luna: a fictional male, black-and-white Border Collie mix last seen in ZIP 78613. Snowflake ranked public intake record 31498 first with a score of 100.
The interface exposes the breed, color, sex, location and timing contributions instead of reducing the result to an unexplained confidence number. The record still needs to be checked with the shelter using its public animal ID.
The live Snowflake search produced query ID 01c66412-0005-6537-0000-0001966e91b9; its four-source lineage query was 01c66413-0005-642d-0000-0001966e71c9.
I then ran Scout, the fictional negative control. The leading live candidate scored 65.3, below the automatic threshold of 78, and had conflicting breed evidence. Snowflake selected no candidate. The hosted fixture makes the same behavior easy to replay with a harsher contradiction:
That is the result I care about most. A matching system should demonstrate not only what it can retrieve, but also when it will stop.
Code
The application uses React and TypeScript for the case-file interface, an Express API, the Snowflake Node SDK with key-pair authentication, and checked-in SQL for setup, loading, modeling, contracts and parameterized ranking.
The repository's first commit was made on August 14 after the challenge opened. The final gate includes 62 tests across nine files, TypeScript checking, a production build and a dependency audit with zero known vulnerabilities. GitHub Actions independently reruns the complete gate before deploying the fixture demo.
How I Built It
Snowflake is the matching system, not a database logo attached afterward.
The live run loaded four City of Austin feeds:
| Feed | Rows |
|---|---|
| Current intakes | 5,586 |
| Current outcomes | 5,643 |
| Historical intakes | 94,608 |
| Historical outcomes | 94,505 |
| Total | 200,342 |
Snowflake normalizes breed, color, sex, ZIP and timestamps. It removes current intakes that have a later outcome, calculates historical return-to-owner context and produced 551 unresolved current dog records for this run.
Each candidate receives inspectable contributions:
| Factor | Weight |
|---|---|
| Breed | 32 |
| Color | 20 |
| Location | 18 |
| Sex | 16 |
| Time | 14 |
A high aggregate score is not enough. Automatic selection also requires at least 60% evidence coverage, no hard chronology or known-sex conflict, and an eight-point lead over the runner-up. Snowflake performs retrieval and ranking. The shared application matcher checks the safety gates again before the interface can show a possible match.
The first live model execution found a real integration bug. Snowflake inferred NUMBER(16,6) inside a SQL function declared to return FLOAT. Explicitly casting the complete result repaired the function. The automated gate stayed green, and the live model then passed all 17 SQL contracts: four timezone cases, four ZIP-extraction cases and nine breed/color parity cases.
I used separate review passes to challenge the matcher, current public-feed schema, privacy boundary and live Snowflake path. A finding counted only when it could be reproduced as a test, SQL contract or browser-visible failure.
The API authenticates with an encrypted key pair through the dedicated BARK_BACK_HOME_APP role. Query history showed both searches and both lineage queries completing under that role:
A direct application-role query against a raw ingest table was denied. The public-facing path can read modeled views and functions, not the staged raw payloads.
The current refresh is intentionally modest: validated truncate-and-copy loading for a private hackathon demonstration. A continuously operated service should replace it with shadow tables and an atomic swap.
Prize Categories
Best Use of Snowflake
This is the only technology category I am entering.
Snowflake performs the central work: loading four public datasets, normalizing inconsistent descriptions, filtering resolved records, calculating historical context, ranking candidates and retaining query and lineage receipts for the answer shown to the user.
Without Snowflake, Bark Back Home is a case-file interface. With Snowflake, it becomes an explainable public-record search desk, including the ability to say that the responsible answer is to keep looking.
