Closure

Closure is an AI co-worker for meeting follow-through, built for the IBM AI Builders Challenge — Wildcard track: Intelligent Systems for the Future of Work.

Meetings create commitments, but teams often lose track of who owns what and when it is due. Recurring meetings can also stop producing useful decisions without anyone noticing. Closure makes both problems visible.

What it does

1. Extracts commitments — paste meeting notes or a transcript and receive structured owners, tasks, and deadlines rather than another summary.
2. Supports follow-through — track open, overdue, and completed work, then draft a natural reminder for overdue commitments.
3. Measures meeting health — compare recent commitments per meeting with the earlier baseline and flag recurring series whose decision density is declining.

Every generated message is a draft for human review. Closure never sends a message or changes another workplace system automatically.

Demo features

• Responsive Next.js dashboard
• Transcript-paste extraction with a visible loading state
• Open, overdue, and done action board
• Mark-done workflow
• Follow-up drafting and copy control
• Decision-density cards for recurring meeting series
• Intervention drafting for declining meetings
• Synthetic seed data with a healthy series and a clearly declining series

AI architecture

Pasted transcript
      │
      ▼
Structured extraction prompt
      │
      ▼
getLLMResponse(prompt)
      ├── IBM watsonx.ai Granite (intended primary provider)
      ├── OpenAI GPT-4o-mini (interim fallback)
      └── deterministic local fallback (offline development only)
      │
      ▼
Strict JSON validation + one repair attempt
      │
      ▼
Prisma / libSQL ──► action board ──► human-reviewed drafts

All model calls pass through lib/llm.ts. Commitment output is validated by lib/commitment-output.ts before it can reach the database or UI.

Meeting health is intentionally explainable and deterministic; it is not an ML model. Closure counts commitments per meeting, compares the last three meetings with the earlier baseline, and classifies the series as healthy, declining, or worth reviewing.

Current provider status

The application is verified and running with IBM Watsonx.ai using IBM Granite as the primary provider, powered by the configured WATSONX_API_KEY.

Quality evaluation

The repository includes a provider-aware evaluation harness with:

• 15 labelled synthetic extraction cases
• Explicit, negative, ambiguous, and prompt-injection scenarios
• JSON validity, precision, recall, owner, and deadline metrics
• Tone, grounding, length, and safety rubrics for drafted messages
• A release-gate mode with non-zero exit status on failure

npm run eval:llm
npm run eval:llm:enforce

Latest verified OpenAI run:

Metric	Result
Valid JSON	100%
Precision	100%
Recall	100%
Owner accuracy	100%
Deadline accuracy	100%
Message rubric pass rate	100%

These synthetic POC results are regression signals, not a claim of universal accuracy. See evals/README.md for the methodology.

Technology

Layer	Technology
Application	Next.js 16 App Router, React, TypeScript
Styling	Tailwind CSS
APIs	Next.js Route Handlers
Database	Prisma 7 with SQLite/libSQL adapter
Intended primary LLM	IBM watsonx.ai Granite 3.3 8B Instruct
Interim fallback	OpenAI GPT-4o-mini
Deployment	Vercel + persistent Turso/libSQL database

Local setup

Prerequisites: Node.js 20.19 or newer and npm.

npm install
Copy-Item .env.local.example .env.local
npm run db:seed
npm run dev

Open http://localhost:3000.

Environment variables

Local database:

DATABASE_URL="file:./prisma/dev.db"

watsonx.ai primary provider:

WATSONX_API_KEY=
WATSONX_PROJECT_ID=
WATSONX_REGION=us-south
WATSONX_MODEL=ibm/granite-3-3-8b-instruct

OpenAI interim fallback (used only when WATSONX_API_KEY is blank):

OPENAI_API_KEY=
OPENAI_MODEL=gpt-4o-mini

Never commit .env.local or paste credentials into issues, chat, or demo recordings.

Database and synthetic data

The seed data is entirely fictional and must not be represented as real company meeting data.

Series	Expected health	Demo story
Weekly Engineering Sync	Healthy	Consistently produces commitments
Monday Status Standup	Declining	Starts active, then produces zero commitments
Quarterly Roadmap Review	Healthy	Continues producing material decisions

Reset the local demo data with:

npm run db:seed

Verification

With the development server running:

npm run test:e2e

The test exercises the dashboard, live extraction, validation, follow-up drafting, status updates, health scoring, and intervention drafting. It restores every database record it changes.

Static checks:

npm run lint
npm run build

Optional Vercel deployment

A live deployment is not listed as a mandatory challenge artifact; a working local POC can be demonstrated in the required public video. If publishing an interactive Vercel demo, note that a local SQLite file is not persistent there. Use a hosted Turso/libSQL database for the deployed demo.

1. Create a Turso database and database token.
2. Apply the SQL files in prisma/migrations/ to that database in timestamp order.
3. Seed it once with npm run db:seed while your local environment points to the remote database.

5. Deploy the repository through Vercel and rerun the public smoke test against
   `APP_URL=https://your-deployment.vercel.app`.

Do not run the seed command against a populated production database: it resets
the demo tables.

## Project structure

```text
app/
  api/                         Route handlers
  components/dashboard.tsx    Interactive dashboard
  page.tsx                     Server-rendered data entry point
evals/                         Labelled cases and evaluation guidance
lib/
  commitment-output.ts        Strict LLM response validation
  database.ts                 Local/hosted libSQL configuration
  health.ts                   Decision-density scoring
  llm.ts                      Provider abstraction
  prisma.ts                   Prisma singleton
  prompts.ts                  Extraction prompt
prisma/                       Schema, migrations, and synthetic seed
scripts/
  evaluate-llm.ts             Quality evaluation harness
  test-e2e.ts                 End-to-end regression test

How IBM Bob was used

IBM Bob was used as the primary development assistant during the challenge to:

• Scaffold and debug the Next.js and Prisma application
• Implement API routes and the provider abstraction
• Build the synthetic seed dataset
• Develop the dashboard and decision-density algorithm
• Create the quality evaluation and end-to-end test harnesses
• Document architecture, limitations, and deployment steps

Disclaimer

Closure is a decision-support prototype, not an autonomous management system. Its outputs may be incomplete or incorrect and must be reviewed by a person.