LifeGuardian

One delayed flight can unravel an entire evening. LifeGuardian maps the consequences, finds a recovery, and knows when to stop before crossing your limits.

Comment

LifeGuardian: Incident Response for Real Life

Your life has dependencies. LifeGuardian stops one disruption from becoming five.

Inspiration: One delay. Five problems.

Imagine landing three hours later than expected.

Your airport pickup has already passed its waiting window. Your anniversary dinner is at risk. Your child needs someone at home before your mother leaves. And your mother still needs to catch the last ferry.

You have not simply missed a flight connection. You have disrupted a network of promises involving people who depend on you.

Now imagine having to fix everything manually.

You check arrival times, contact transport providers, rearrange dinner, find alternative childcare, calculate additional costs, coordinate with family members, and hope that solving one problem does not create another.

This is the problem that inspired LifeGuardian.

Today's calendars are excellent at storing commitments. AI assistants are increasingly capable of answering questions and performing individual tasks.

But our lives are not collections of independent tasks. They are networks of dependencies.

When something changes, the real question is not merely "What should I reschedule?" It is "What else will this affect, and how do I protect what matters?"

That is the question LifeGuardian was built to answer.

What we built: A personal continuity engine

LifeGuardian is a consequence-aware recovery system that understands the relationships between commitments, identifies what a disruption puts at risk, evaluates recovery options, and coordinates actions within explicit human authorization.

Its purpose is straightforward:

Help people keep important commitments when life does not go according to plan.

For our illustrative delayed-flight scenario, LifeGuardian's deterministic Rippleproof engine evaluates 126 recovery combinations and identifies 15 feasible options within a $150 budget.

But finding alternatives is only the beginning.

We wanted people to understand the consequences of each choice, remain in control of actions taken on their behalf, and know precisely what happened afterward.

That led us to build four interconnected capabilities.

1. Future Fork: See the consequences before choosing

The Future Fork turns a complicated recovery decision into an understandable comparison.

The person sees two views of the same evening:

If nothing changes: Four commitments remain disrupted. The application shows why each one is affected and the estimated cost of leaving the situation unresolved.

With Plan A: The same dependency network shows which arrangements would change, how much the proposed recovery would cost, and which commitments become achievable again.

The most revealing detail is Mom's ferry.

LifeGuardian does not modify the ferry itself. Instead, the proposed recovery changes earlier arrangements so that Mom can reach it with 15 minutes to spare in the modeled schedule.

The system understands that protecting one commitment can restore several others.

This is consequence-aware planning, not simply moving calendar events.

Every proposed action remains visibly marked as a proposal. Comparing plans does not execute anything.

2. Rippleproof Assurance: Understand how a plan holds up

A plan can look good on paper and still be fragile.

LifeGuardian allows people to rehearse possible failures before authorizing a recovery.

What if the replacement restaurant table is unavailable? What if the sitter cannot confirm? What happens to the budget and the commitments that depend on that action?

Rippleproof Assurance runs these scenarios on an isolated copy of the current recovery state. The Decision Lens then compares the plans by what they preserve, what they cost, and how they respond when individual steps fail.

We also built Aftershock to examine what happens if the proposed fallback encounters another disruption.

These are deterministic scenario rehearsals, not invented predictions or statistical failure probabilities.

The goal is to help the person make a better-informed choice before committing time, money or permission.

3. Rescue Mandates: Give the agent capability, not unlimited authority

We believe the next generation of AI agents must do more than perform actions.

They must understand the boundaries of those actions.

In LifeGuardian, approving a recovery creates a Rescue Mandate that records the permitted steps, providers, spending ceiling, binding offer and expiration.

The server signs the mandate and enforces it through 14 deterministic policy checks.

These checks run before execution. They are separate from the language model, and an MCP tool cannot grant itself new authorization.

This distinction becomes unmistakable in our demonstration.

The person approves a plan that includes Jamie, a sitter offered by the fictional Brightside agency, for $79.

Brightside then declines Jamie and offers Priya for $89. This is a controlled demonstration condition.

The new offer might appear reasonable, but it is not what the person approved.

LifeGuardian stops.

It explains the difference between the original approval and the replacement offer. The unused $79 sandbox payment hold is released, Priya is not booked, and the remaining dependent operations wait for a new decision.

The application remembers that $27 has already been spent on earlier simulated actions and proposes a revised recovery costing up to $89 more, for a total potential exposure of $116 within the $150 budget.

The person must authorize the replacement separately.

The most important thing our agent demonstrates is not that it can act. It is that it knows when it must stop.

4. Outcome Ledger: Make recovery accountable

A successful API response does not necessarily mean the real-world problem has been resolved.

A booking confirmation does not prove that a sitter arrived. A calendar hold does not mean another person agreed. A payment authorization is different from a completed charge.

The Outcome Ledger preserves these distinctions.

It records the status of each commitment, the evidence supporting that status, the financial consequences and which outcomes remain to be confirmed.

For our demonstration, the final state is accurately described as "Covered on paper."

That is an important engineering principle: an intelligent system should report the evidence it has, not the outcome it hopes occurred.

How it works: Agentic intelligence with deterministic control

LifeGuardian combines a conversational interface, a real MCP server, a consequence-aware planning engine and a bounded execution system.

Amazon Bedrock provides language understanding.

We integrated Amazon Bedrock through the Converse API using the AWS SDK for JavaScript. With Amazon Nova Lite configured, LifeGuardian can interpret natural-language requests and follow-up questions.

Model Context Protocol connects the assistant to the recovery system.

Our self-hosted MCP server supports Streamable HTTP and MCP protocol version 2025-11-25. The Ask LifeGuardian interface is a working MCP client that initializes a connection, discovers available tools, invokes recovery functions and displays the resulting activity.

This provides an Alexa+-style experience through our own web interface, using the self-hosted MCP approach permitted by the hackathon.

Rippleproof handles the decisions that require exact answers.

The deterministic engine computes dependency impacts, time windows, feasibility, spending and plan rankings. The language model does not invent provider availability, change authorized prices or decide which actions the person has permitted.

Rescue Mandates enforce authority.

Every operation is checked against the approved scope. Changes to an offer can require fresh human consent.

The Outcome Ledger records evidence.

The result identifies which simulated operations were accepted, which were stopped and which outcomes remain unverified.

Our design principle is:

Bedrock interprets. Rippleproof plans. People authorize. The system verifies what it can.

Built using Amazon Web Services

LifeGuardian has an existing cloud deployment using:

  • Amazon EC2 Graviton to run the application on ARM64 infrastructure.
  • Amazon CloudFront to provide a public HTTPS endpoint.
  • Amazon EBS for encrypted application data storage.
  • AWS IAM instance roles for server-side AWS access without embedding long-lived credentials.
  • AWS Systems Manager for server administration.
  • Amazon Bedrock Runtime for natural-language interpretation through the Converse API.

The earlier AWS-hosted release demonstrates the cloud architecture and Bedrock integration.

Our submitted hackathon candidate expands the product with the complete M12 recovery and authorization experience, including Future Fork and the Authority Circuit Breaker. The candidate is reproducible from the submitted GitHub source.

For the AWS Builder Mini Challenge, Amazon Bedrock is a genuine application integration, not merely an AWS service mentioned in our documentation.

Design: Make complex decisions understandable

LifeGuardian deals with decisions that involve money, other people and potentially significant consequences.

That makes clarity as important as technical capability.

We built the interface around a clear progression:

What changed → What breaks → What can be recovered → What you authorize → What actually happened.

The Future Fork uses one stable dependency network rather than forcing the person to mentally compare unrelated diagrams.

Proposed changes are visibly distinguished from completed actions.

The authorization interface presents spending exposure and permission boundaries before execution.

The refusal experience explains the changed offer in ordinary language rather than hiding the reason inside an error code.

And the Outcome Ledger makes the result understandable after the recovery.

The interface is intentionally calm, readable and focused on decisions.

Who LifeGuardian is for

LifeGuardian starts with people whose commitments affect other people.

Working parents need to coordinate travel, childcare, appointments and family commitments when schedules change.

Caregivers must manage handoffs and responsibilities that cannot always be postponed.

Frequent travellers deal with disruptions involving transportation, reservations and time-sensitive obligations.

Households with interconnected schedules need a reliable way to understand how changes affect everyone involved.

These people are not simply looking for another productivity tool.

They need help preserving important commitments when an unexpected event forces several decisions at once.

When and where people would use it

LifeGuardian is designed to be useful across three moments:

Before a disruption: Understand dependencies and rehearse how important plans would hold up.

During a disruption: Identify affected commitments, compare recoveries and coordinate approved actions.

After a disruption: Review what happened, what was spent and what still needs attention.

Today, LifeGuardian provides a web application and an MCP tool interface for compatible AI assistants.

Our longer-term vision includes integration with household calendars, travel services, caregiving providers and communication channels such as Telegram.

Telegram notifications and coordinated family updates are a natural extension of LifeGuardian's existing dependency and approval model. They are part of our planned product roadmap, not a feature claimed as implemented in this submission.

Engineering challenges and what we learned

The central engineering challenge was making a multi-step AI-assisted workflow dependable when the world changes during execution.

We addressed this by separating language interpretation from deterministic decision-making, building authorization checks into the execution path, and preserving the current state after partial success or failure.

A second challenge was modeling a changing provider offer. Our stateful Brightside sandbox supports signed offers, idempotent orders, counter-offers, simulated payment holds and reconciliation after uncertain responses.

A third challenge was making a complex dependency graph understandable. The Future Fork lets users inspect a recovery without confusing a proposed outcome with an actual completed action.

We also implemented repeatable protocol and browser verification, including recovery and authorization regression tests.

The final submitted candidate passed:

  • 1,190 unit tests, with 9 skipped.
  • 43 browser tests.
  • 67 end-to-end MCP proof checks.
  • Lint, type checking and the production build.

These results were verified locally on the final candidate before its GitHub publication.

What we are most proud of

We are proud that LifeGuardian is not merely a conversational interface that suggests what somebody should do.

We built a system that reasons about consequences, presents meaningful alternatives, respects exact authorization, responds to a changing offer, and accounts for the resulting actions.

The moment that best represents the project is when the provider offers a different sitter.

The application has enough information to continue, but it does not have the authority.

So it stops.

That is the kind of judgment we believe people will need from increasingly capable AI systems.

The opportunity beyond the hackathon

We see LifeGuardian as the foundation of a new kind of personal continuity infrastructure.

Instead of interacting with isolated booking applications, calendars and communication services during a stressful disruption, people could use one coordinated recovery layer that understands relationships and respects their preferences and permissions.

A possible initial commercial model is a household subscription for high-dependency schedules, with longer-term distribution opportunities through travel platforms, employee benefits, caregiver-support services and financial-service partners.

These are commercial directions to validate as we develop integrations with real service providers.

The underlying need is much broader than the flight-delay demonstration: people need their commitments to work together, especially when circumstances change.

LifeGuardian is built around one idea: the future of useful AI is not just doing more on our behalf. It is understanding what matters, preserving our choices and knowing when to stop.

Demonstration context: The flight, characters, providers, bookings and payments in our scenario are fictional or sandboxed. The MCP server, planning engine, authorization logic, sandbox merchant state machine and outcome-accounting software are implemented. The submitted candidate is available in the linked GitHub repository with reproducible local testing instructions.

Built With

Share this project:

Updates

Submission history