KINTA: Impact & Recovery Intelligence

What inspired KINTA

An event does not fall apart in one place. When a hall cancels, the food, the photographer, and the equipment were booked around that room, and some of that money is already paid. The organizer still has to decide the same day: cancel, keep the date and find another hall, or move the date.

Most tools either track the budget or chat about the problem. Neither one shows who is actually affected, what each choice costs, and which pesos are safe to refund. That gap is why we built KINTA, an AI recovery tool for organizers who have already spent the money.

What it does

KINTA follows one event from the notice to the refund.

The organizer types what happened. The AI reads that text and labels the incident. In our demo, a hall cancellation becomes a supplier cancellation, with a confidence level and a list of facts it still does not know.
A dependency check separates a direct hit from an indirect one. The hall is named in the notice. Catering is affected because it needed that room. Photography can stay unmarked, because the photos follow the date, not that exact hall.
KINTA drafts three plans: Cancel, Relocate, and Reschedule. The AI writes the choices. A separate calculator does the pesos, in centavos, and labels each figure as confirmed, an assumption, or still waiting on a supplier.
PayPal does not run because a plan exists. A person creates the refund and approves it. Until then, the money stays put.

The AI is not allowed to decide that a deposit is legally owed. If the notice does not say what happens to the money, that gap stays on the screen.

How we built it

We split the work into a backend and a product surface, then joined them in one Next.js app.

Backend: Prisma and SQLite for the event, suppliers, contracts, and the incident. Zod checks every amount before it is stored. The dependency engine and the financial simulator are deterministic, so the same inputs always produce the same pesos.
AI: Gemini when a key is present, and a heuristic reader for an offline demo. Both paths return the same kind of result: incident type, who is affected, assumptions, and missing information.
Product: A lobby, then one active event across the dashboard, suppliers, the disruption page, the dependency map, recovery plans, and the simulator.
PayPal: A refund is a real action with a PayPal badge. It waits for approval. Mock mode lets us demonstrate the gate without charging anyone.

The demo event is University Tech Summit: 15 December 2026, Quezon City, 100 people, a ₱60,000 budget, and a ₱7,500 hall deposit already paid.

What we learned

The useful line for the AI is narrow. It should read the notice and name the incident. It should not do the final math, and it should not invent a legal refund. Organizers trust the screen when every number says whether it came from the ledger or from a guess.

We also learned that a recovery tool is a sequence, not a chatbot. Report, analyze, check dependencies, price the three plans, then ask a person before money moves.

Challenges

Keeping the AI honest. Early drafts filled in the deposit outcome. We changed the prompt and the UI so missing facts stay missing, and so the copy says the result is an extraction, not a legal decision.
One active event. The sidebar kept showing the same project after a switch. We stored the choice in a cookie and made suppliers, disruptions, plans, and payments read that event.
Money that jumped between server and browser. Peso and date formatting did not match, so the page flickered. We switched to a fixed format so the figures stay still.
A file database on a host that forgets. SQLite is simple locally. On a free host, a restart can wipe what you typed. The demo seed puts the event back, but a live organizer would need a database that persists.