FairChange

• 

  Hero

• 

  Workflow

• 

  Human Approval

• 

  Independent Session

Inspiration

Scope changes are where delivery work often becomes unprofitable. A client asks for “one more change,” but the answer is scattered across signed scope, emails, estimates, and delivery tasks. Teams then spend hours reconstructing what was agreed, or make a promise before checking the record.

I have spent 18 years in sales and operations. I lost business during COVID, then lost my mother to cancer, and hit rock bottom. While rebuilding, I kept returning to the same work problem: important commitments were being managed from memory and scattered documents.

That led me to build ScopeLedger. FairChange is the focused capability I built for this hackathon.

What FairChange Does

FairChange helps implementation teams classify a client request as:

• a defect against an agreed acceptance criterion
• included work within the existing allowance
• a new scope change requiring commercial approval

The agent gathers the relevant evidence, explains the decision, and proposes the next safe action. It automates the repetitive search while keeping the commercial decision with accountable people.

How I Built It

FairChange runs an assessment agent inside Amazon Bedrock AgentCore Runtime using Strands Agents. The agent uses read-only retrieval tools over a synthetic engagement containing scope clauses, correspondence, estimates, and delivery tasks.

Each assessment returns structured evidence, a decision, ambiguity information, and a proposed task. The domain layer validates that the evidence exists and belongs to the correct engagement.

For a scope change, the workflow pauses at a human gate. An owner must authorize the exact proposal version, and the client must accept that same version before the scope revision and delivery task are persisted.

The runtime is protected by a Cognito JWT authorizer. IAM remains the deployment and administration path. The public demo is a separate, read-only synthetic workspace and never exposes credentials or tokens.

What I Learned

The hardest part was not making the model produce an answer. It was deciding what the model must never be allowed to do.

A prompt saying “ask for approval” is not enough. The boundary must exist in typed state, validation rules, permissions, and tests. The agent can retrieve, compare, explain, and prepare. People still authorize the commitment.

I also learned that evidence is part of the product. A confident answer is not useful if nobody can trace it back to the record that supports it.

Challenges

I built the project while learning more of the software and AWS stack from the ground up. The work required repeated debugging across local workflows, AgentCore deployment, authentication, evidence validation, persisted state, and the judge-facing experience.

The project uses synthetic data and does not claim customer savings or autonomous commercial authority. The next step is to connect this pattern to a production system such as ScopeLedger or a CRM with the host application's identity and permissions.

FairChange is a prototype, but the problem is real: teams need faster answers without giving an AI agent the authority to make promises on their behalf.

Accomplishments that we're proud of

We built an end-to-end evidence-backed workflow, deployed the agent on Amazon Bedrock AgentCore, added Cognito authentication, implemented evidence validation, and created a public interactive demo with a human approval gate.

What we learned

Reliable agents need more than a strong prompt. They need bounded tools, typed evidence, deterministic validation, and explicit points where human authority takes over.

What's next for FairChange

The next step is connecting FairChange to ScopeLedger or a CRM with real permissions, current project records, stronger evaluation, and production data controls.

Built With

• amazon-web-services
• bedrock
• github
• iam
• json
• pages
• python
• react
• remotion
• strands
• typescript