Terralia

Context & constraints

Terralia emerged from the inspiration of seeing a project a relative ran in Peru, where people are taught to cook using what grows in their local environment. That gave me the premise: in the Andes, communities survived and thrived for centuries thanks to local resources, and much of that capacity remains — right there in the land; it simply isn’t in circulation.

The tension underneath it is economic. Raw resources leave the valley cheap, get processed abroad, and come back as branded products bought by the same people who could have made something equivalent for free or near-free. That is not a problem software can fix. But it explains why not knowing is expensive.

What limited me, honestly:

• Two weeks, fixed by the course calendar — 30 June to 14 July 2026.
• Berlin. I designed for Quechua- and Spanish-speaking comunidades campesinas from 11,000 km away, with no way to sit with anyone while I worked.
• Solo, no budget. No researcher, no botanist, no engineer.

This project is not speculative like Immunify: no invented capability. Nothing in the demo does something a real system couldn’t plausibly do with real data. The data is illustrative; the behaviour is not faked in principle.

Strategy

Who this is for

Not “rural people.” One person: an adult roughly 30–60 in a comunidad campesina of the Sacred Valley, the household’s health decision-maker, who also manages small livestock, stored food, and repairs to the house.

One person, one continuous job, four recurring problem domains.

That framing is why Terralia isn’t a remedies app — the tool follows the person’s life, not a category.

Residents, not tourists

Tourists are the easier market: they pay, they’re reachable, and Cusco is full of them. I refused them because the value of this idea is that the knowledge returns to the people who own it. Foreign visitors would be an added value later, never the objective. I chose a harder, poorer, less reachable audience over an obvious one because targeting outsiders would have inverted the project’s entire point.

Quechua as a stance, not a feature

Designing only in Spanish would exclude the monolingual Quechua speakers who most often hold the knowledge Terralia claims to protect. It also shapes the architecture — a system trained on both languages of one place is cheaper to run than a general model translating into a minority language.

The outcome is named in the user’s words

The health screen labels its projection bienestar general. That is not a clinical measure and was never meant to be one — it is the phrase this household already uses for how things are going when someone is unwell. The other three domains don’t share it: what changes when an animal recovers, when stored food keeps through the season, or when a roof stops leaking each has its own word, and none of them is bienestar general. One system, four vocabularies. Only the health domain is built — for now this is the rule, not the product.

Sustainability in the ranking, not in the copy

I rejected the eco-tool framing — but not because people in the valley don’t think about sustainability. At a festival in Ollantaytambo, someone told me you can’t take trout at certain times of the year: you wait until they have reproduced. That is a conservation rule, held as practical knowledge and expressed as a season rather than as an identity. One conversation is not research and I won’t call it that — but it changed what I was designing. An app that asks people to care about sustainability is telling them something they already know, in a vocabulary they don’t use. So conservation is enforced by the mechanic instead of asked for by the message:

Obtainability includes season — an out-of-season resource dims and drops to the bottom of the list.

Process

Week 1 — concept, flow, and a first working prototype. Week 2 — the ranking variables, the visual system, the before/after projection, and real map locations.

What I discarded

Terralia as a medical system. The first version was built to heal: you describe an illness, the system returns a herbal treatment. I dropped that premise because it doesn’t survive the evidence — as far as science reaches, the plants growing around this valley don’t resolve complex conditions, and those need a professional. A product built on that promise would fail exactly where failing costs the most. So health became one of four household domains instead of the whole product: the everyday matters a household already handles itself, with the cautions saying plainly when to stop and see someone.

What I never corrected

The concept itself never changed. Week 2 added features to week 1’s idea rather than correcting it — because there was no user in the loop to correct it.

AI in the workflow

I built the prototype with Claude Code (Opus 5). It wrote all the code. Without it, two weeks alone would have produced screens you click through, not a system that runs.

AI executed. I decided.

The concept, the audience, the flow, the four domains, the three variables, the choice to show scores instead of an answer, the visual encoding, the Quechua position — none of that went through a model. I did use Claude Design to explore layouts, and some screens started as options it generated — I chose between them, corrected them, and directed what came next. The drafting was shared; the judgement was not.

Where I used AI and shouldn’t have relied on it

The domain knowledge. I’m a designer, not a botanist, and I used AI research to assemble the plant and compound content so I could test whether the system behaved. It is specific enough to check — species names, the volatility of pulegone, dosage limits — and I didn’t check it. That was the right move to prove an interaction and the wrong basis for anything a person would act on. At scale it has to be replaced by primary sources: interviews, local expertise, published ethnobotany. Saying so is part of the design position, not an apology for it.

The architecture argument

I proposed a purpose-built model per region rather than a general API with retrieval: the knowledge base is large, the data is culturally sensitive and should stay private, and a narrow model is far cheaper per query. The cost is scalability — one model per valley doesn’t extend cleanly to the world. That’s the hardest call in the project and I’d still defend it, because a system that is generic everywhere is trustworthy nowhere.

Craft

Outcome & learning

The project was approved as coursework. What it produced is a running prototype and an argued system design that turns a spoken goal into ranked, seasonal, located options.

What I validated: the interaction model is legible without instructions, and the three-variable encoding communicates a ranking faster than text does.

What I did not validate: everything else. No one from the Sacred Valley has seen Terralia. The scores are hand-set to demonstrate behaviour, not derived from data. The knowledge base is illustrative — the plant and compound content still has no published source attached to it.

Next, in order: source tags on every card, so provenance is visible in the product and not only in the deck; entries verified against real published sources; and conversations with people in the valley, starting with the people my relative worked with.

Nothing here promises anything. The three scores are probabilities — how likely a resource is to be available, to work, and to be within reach — and the projection on the result screen is the same kind of estimate applied to the outcome: for this household, with this resource, how much is likely to change. The system is built to learn one household over time, so those estimates get more personal the longer it runs. In the demo the figure is set by hand like every other number on the screen: the reasoning is real, the value is illustrative.