Skip to content
SKSuraj Kumar

Contract operations

Contract Intelligence & Obligation Tracking

Reads contracts against a company’s own negotiation playbook, cites the exact clause behind every flag, and turns obligations and notice periods into dated reminders.

  • AI system
  • AI
  • Legal operations
  • Risk
  • Next.js
Role
Sole engineer. Clause segmentation, playbook rule model, date resolution logic and the review interface.
Work type
Private client project
Timeline
9 weeks build effort · 2026
Status
Case study published
Client
Private client work

Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.

Technical previewDiscuss a build like this

Interface built in code for this case study — not a client screen capture.

01Business problem

What was actually going wrong

Companies sign contracts they then forget the contents of — auto-renewals trigger, notice windows close, and non-standard clauses were only spotted because someone happened to read carefully.

Who feels it

  • Founders and operators signing contracts without in-house counsel
  • Commercial teams negotiating against no written standard
  • Finance, discovering renewals after they have triggered
  • Anyone asked what a signed contract actually commits them to

Contract review at a company without a large legal function is a person reading a PDF against what they remember the company usually accepts. It works until volume rises. Then the same non-standard indemnity gets accepted twice, a liability cap goes in at a multiple nobody would have approved, and a payment term of ninety days is agreed by someone who did not know sixty was the limit.

The bigger cost arrives later. A contract with a twelve-month term and automatic renewal unless notice is given sixty days prior contains a date that nobody put in a calendar. The window closes, the contract renews, and the company pays for another year of something it intended to stop.

Obligations have the same problem. Reporting requirements, insurance certificates, data deletion on termination — all agreed in writing, none tracked anywhere, and each one only discovered when the counterparty asks.

02Product overview

What got built

A contract review system that segments an agreement into clauses, classifies each one, compares it against a structured playbook of acceptable and fallback positions, flags deviations with the clause text quoted, and extracts dates and obligations into a tracked calendar.

Engineering notes

  • Playbook encoded as structured positions, not prompted risk judgement
  • Every finding grounded in a quoted clause span
  • Term-aware resolution of relative notice deadlines
  • Dismissal reasons aggregated to tune rules by evidence

The playbook is the centre of the design. Rather than asking a model whether a clause is "risky", the company’s own positions are encoded per clause type — preferred, acceptable fallback, and unacceptable — with the conditions that distinguish them. A flag is then a specific statement: this liability cap is at three times fees where the playbook permits one times, quoted from clause 11.2.

Every finding carries the clause span it came from. Nothing is asserted without a quotation, because a legal review tool that cannot show its source is not usable — a reviewer has to be able to read the clause and disagree. Findings have a severity, a playbook reference and a suggested fallback position drawn from the playbook rather than generated.

Dates are resolved, not just extracted. A notice obligation expressed as "sixty days prior to the end of the then-current term" is computed against the actual effective date and term length into a concrete date, with the derivation shown. Those dates become reminders, and the obligations become a tracked list per contract.

The system deliberately stops short of advice. It reports what a clause says, how it compares to the company’s stated position, and what date follows from it. It does not tell anyone whether to sign, and the interface says so.

03Key features

What the software does, feature by feature

10 capabilities, of which 2 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.

  • 01

    Clause segmentation

    Contracts are split into clauses that survive real-world numbering — decimal, roman, lettered schedules and unnumbered recitals.

  • 02

    Clause classificationmodel-backed

    Each clause is typed — limitation of liability, indemnity, term and renewal, payment, confidentiality, data protection, termination.

  • 03

    Playbook comparison

    Clauses are evaluated against encoded preferred, fallback and unacceptable positions rather than a general notion of risk.

  • 04

    Quoted findings

    Every flag quotes the clause span it derives from, with severity and the playbook rule it references.

  • 05

    Suggested fallback language

    Where a clause is outside policy, the fallback position from the playbook is offered as the counter-position.

  • 06

    Date resolution

    Relative dates — notice windows, renewal deadlines, cure periods — are computed into concrete dates with the derivation shown.

  • 07

    Obligation registermodel-backed

    Ongoing commitments are extracted into a tracked list per contract with owner and recurrence.

  • 08

    Renewal calendar

    Notice deadlines and renewal dates across the portfolio in one view, with lead-time alerts.

  • 09

    Template comparison

    A counterparty draft can be diffed against the company’s own template to show what was changed and where.

  • 10

    Portfolio view

    Contracts by counterparty, value band, expiry and outstanding findings, so exposure is visible without opening files.

04User flow

How a person moves through it

The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.

  1. 01Commercial leadUploads a counterparty draft or an executed agreement.
  2. 02SystemSegments the document into clauses and classifies each by type.
  3. 03SystemEvaluates each clause against the playbook and produces findings with quoted spans.
  4. 04SystemResolves relative dates against the effective date and extracts obligations.
  5. 05ReviewerWorks the findings list, reading each quoted clause and accepting or dismissing the flag with a reason.
  6. 06ReviewerUses the playbook fallback language to prepare a counter-position.
  7. 07OperationsOwns the resulting obligations and receives notice-deadline alerts ahead of each date.

05Architecture

How it is put together

The processing path first, then the layers it runs on, then the constraints that shaped both.

Path through the system

6 stages

  1. 01

    Ingest

    Document parsed to text with layout retained for span offsets.

  2. 02

    Segment

    Clause boundaries detected across numbering conventions; spans recorded.

  3. 03

    Classify

    Clause type assigned with confidence; unknown types kept as unclassified.

  4. 04

    Evaluate

    Playbook rules produce findings with severity and quoted spans.

  5. 05

    Resolve

    Relative dates computed; obligations extracted into the register.

  6. 06

    Track

    Deadlines and obligations monitored with lead-time alerts.

Layers

Interface
Contract reader with clause navigationFindings list with quoted spans and severityPlaybook editorRenewal and obligation calendarPortfolio table with exposure filters
Application state
Clause + span modelPlaybook rule evaluator (deterministic)Date resolution engineFinding disposition state (accepted / dismissed with reason)
Services
Document parsing with offsetsClause classificationObligation extraction with structured outputTemplate diffing
Records
Contracts with clause spansVersioned playbookFindings and dispositionsObligation and deadline register

Why it is shaped this way

  • The model classifies and extracts; the playbook decides. Separating those two means a finding is traceable to a written company position rather than to a model’s opinion, which is the difference between a report a lawyer will read and one they will not.
  • Every finding stores the character span it quotes. The reader highlights it in the original document, so verification is one click rather than a search.
  • The system reports and does not advise. That boundary is stated in the interface, because a tool that appears to give legal conclusions invites reliance it cannot support.

06Technical decisions

The choices that mattered, and what each one cost

Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.

01

Encode the negotiation playbook as structured rules per clause type instead of prompting for risk.

Why

Risk is company-specific. A ninety-day payment term is unacceptable to one business and routine to another. Encoding preferred, fallback and unacceptable positions makes findings specific, reviewable and versionable.

Trade-off

The playbook has to be written and maintained, which is real work. It is also the artefact that makes the output defensible, and most companies benefit from writing it down regardless.

02

Require a quoted clause span on every finding.

Why

A reviewer must be able to check the machine. A finding without a quotation cannot be verified or disagreed with, and unverifiable legal flags get ignored wholesale after the first false positive.

Trade-off

Findings that would require synthesizing across several clauses are harder to express and are represented as linked findings rather than one combined statement.

03

Resolve relative dates into concrete dates and show the derivation.

Why

The value is a date in a calendar, not a phrase in a PDF. Showing the derivation — effective date, term length, notice period, resulting deadline — lets someone check the arithmetic, which matters because these dates carry money.

Trade-off

Ambiguous drafting genuinely cannot be resolved, so the engine returns an explicit ambiguous result naming the interpretations rather than choosing one.

04

Keep unclassified clauses visible instead of forcing every clause into a type.

Why

Unusual clauses are exactly the ones worth reading. Forcing a low-confidence classification hides them inside a category where the wrong rules get applied.

Trade-off

A reviewer has an "unclassified" list to read. That list is short and it is where the real surprises live.

07Challenges

What was genuinely difficult

Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.

01

Clause segmentation breaking on real contracts, which mix numbering styles and inline definitions.

Approach

Segmentation combines numbering pattern detection across several conventions with layout signals — indentation, blank lines, bold headings — and falls back to sentence grouping under a detected heading when numbering is absent. Every clause keeps its character offsets into the source text so downstream findings can quote precisely.

Outcome

Schedules, annexes and unnumbered recitals stay addressable, which is where segmentation usually fails and takes the findings with it.

02

Notice periods expressed relative to a term that itself renews.

Approach

The date engine models term structure explicitly — effective date, initial term, renewal period, notice period — and computes the next notice deadline against the current term rather than the original one. Where drafting supports more than one reading, it returns an ambiguous result listing each interpretation and its resulting date.

Outcome

Renewal deadlines are correct for contracts already in their second or third term, which is when the deadline actually matters.

03

False positives destroying trust in the findings list.

Approach

Findings are dismissible with a recorded reason, and dismissals are aggregated per playbook rule. A rule generating repeated dismissals is surfaced for revision, so the playbook is tuned by evidence rather than by complaint.

Outcome

The findings list stayed short enough to read, which is the only condition under which it gets read.

08Business value

What it changes for the business

Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.

Operational effect

  • Turns "what we usually accept" into a written playbook that a review can be measured against consistently.
  • Surfaces non-standard clauses with the text quoted, so a reviewer verifies in seconds rather than reading the whole agreement.
  • Converts renewal and notice deadlines into dated alerts, which is where contract mismanagement costs real money.
  • Produces an obligation register, so commitments are owned rather than rediscovered when a counterparty asks.
  • Gives a portfolio view of exposure by counterparty and expiry without opening individual files.

What would change at scale

  • Version the playbook and record which version each review ran under, so a decision made last quarter stays interpretable.
  • Add clause-level precedent — the fallback positions actually agreed in past negotiations — so suggestions reflect what counterparties accepted rather than only what policy prefers.
  • Introduce reviewer-in-the-loop calibration: sample completed reviews, compare findings against reviewer disposition, and report rule-level precision.
  • Support jurisdiction-specific playbook variants, since governing-law differences change which positions are even negotiable.
  • Handle amendments and side letters as a chain against the base agreement rather than as separate documents.

09Interface

The screens where the work happens

Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.

Contract reader

Clause navigation beside the document, with the clause behind the active finding highlighted in place.

Findings list

Deviations with severity, the playbook rule referenced, the quoted clause text and the fallback position.

Renewal calendar

Notice deadlines and renewal dates across the portfolio, with the derivation available per date.

Obligation register

Ongoing commitments per contract with owner, recurrence and next due date.

The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.

10Technologies

What it is built with

Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.

Frontend
  • Next.js App Router
  • TypeScript
  • Tailwind CSS
  • Server Components
AI layer
  • Clause classification
  • Structured obligation extraction
  • Span-grounded findings
Application
  • Segmentation with character offsets
  • Deterministic playbook evaluator
  • Date resolution engine
  • Template diffing
Data
  • PostgreSQL
  • Versioned playbook store
  • Obligation and deadline register

11Technical preview

Structure, models and annotated excerpts

There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.

Technical preview

Implementation detail for this build

Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.

A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.

Inside this section

  • Module and folder structure for the build
  • Data models and the interface contracts between layers
  • 2 annotated implementation excerpts
  • Design notes covering the decisions the excerpts imply
  • The same keyword opens every case study on the site

For private client work, contact me for a walkthrough.

Next step

Need something along these lines?

Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.

Start a projectView work
Email
surajk86808@gmail.com
Based in
Bengaluru, India
Working hours
IST (UTC+5:30)
Availability
Taking new engagements