Dependency and licence audit across a monorepo

For: Engineering lead or open-source compliance owner preparing a release, a sale or a customer audit

Pattern: Map, verify, reduceNeeds scaleDesigned for 40 to 600 agents

The pain today

A monorepo pulls in a very long list of direct and transitive packages, each with its own licence text. Scanners flag by declared name; nobody reads the actual licence files, and one copyleft package in a shipped bundle becomes a legal problem.

The ask

I attached the exported lockfiles, the software bill of materials and the licence files for our monorepo, plus our licence policy. Which packages break the policy, which licences do not match what the package metadata says, and where are we missing notices? Quote the licence text for each finding.

Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.

What you attach or connect

  • Lockfiles or software bill of materials, exported as text
  • Licence and notice files per package
  • Licence policy: allowed, restricted and forbidden terms
  • List of which packages ship to customers

The unit of work

One worker task per one package version with its licence text.

Why a swarm fits

Each package can be judged from its own licence file and the policy alone. No worker needs the rest of the tree, so the floor can be as wide as the dependency list.

Not for

A small service with a short dependency list: a licence scanner and one reviewer finish before a swarm is planned.

The decision tree

5 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

  1. Planner, while planning

    Scope checkYes or no, with a probability

    Before work starts on a unit

    Does the shipping list or the lockfile entry show this package version is distributed to customers, rather than used only for development and testing?

    Sees only: One package's lockfile entry and its row in the shipping list

    Why: Keeps development-only tooling off the budget without ever dropping a package that might ship.

    • Yes: 0.60 or higherthenAccept
    • Unsure: 0.25 up to 0.60thenAccept
    • No: below 0.25thenSkip this unit
  2. Before workers, before a task runs

    Small worker or strong modelA choice among options

    Before a task runs

    Is this licence file a standard licence text, a standard text with edits, or custom wording?

    Sees only: The opening section of one package's licence file

    Why: Standard texts go to cheap workers; edited and custom licences get the strong reader they need.

    • Standard, unmodified textthenAccept
    • Standard text with editsthenEscalate to a strong model
    • Custom wordingthenEscalate to a strong model
    • File missing or unreadablethenMark unresolved
  3. After workers, the judge checks

    Evidence checkYes or no, with a probability

    After a worker answers

    Does the quoted clause from this package's licence file actually impose the obligation the worker classified it under, such as disclosing source when the software is distributed?

    Sees only: The quoted clause, the worker's classification and the matching policy line

    Why: A wrong licence class either blocks a release for nothing or lets a legal problem ship.

    • Yes: 0.90 or higherthenAccept
    • Unsure: 0.50 up to 0.90thenEscalate to a strong model
    • No: below 0.50thenReject and retry
  4. Reconciler, while merging

    Conflict checkA choice among options

    While reconciling

    Do the licence named in the package metadata and the licence text in the file describe the same terms?

    Sees only: The metadata licence field and the opening of the licence file

    Why: Scanners trust metadata; this is where a mislabelled package is caught and kept visible.

    • Same licencethenAccept
    • Different licencesthenMark unresolved
    • Several licences offered as alternativesthenEscalate to a strong model
    • Cannot tellthenMark unresolved
  5. Accountable person, before anything is settled

    Person decidesYes or no, with a probability

    Before anything is reported as settled

    Does this finding place a forbidden or restricted licence inside something that is shipped to customers?

    Sees only: One finding with its dependency path and shipping status

    Why: Whether to replace, disclose or accept a licence is counsel's decision, never the swarm's.

    Accountable: Counsel or the compliance owner decides whether a flagged licence is acceptable and what to replace or disclose.

    • Yes: 0.40 or higherthenAsk a person
    • Unsure: 0.15 up to 0.40thenAsk a person
    • No: below 0.15thenAccept

The fleet: who does what

Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.

  1. Planner

    A strong reasoning model turns the policy into a checklist and groups packages by ecosystem and shipping status.

    Decisions here:1. Scope check

  2. Workers

    Small fast workers from an open-weight family each read one package's licence text and answer the checklist with quotes.

    Designed for 40 to 600 agents, one worker task per one package version with its licence text. Each worker receives only its own unit.

    Decisions here:2. Small worker or strong model

  3. Judge, from a different model family

    A decision model from a different family checks each quoted clause really supports the licence classification.

    Decisions here:3. Evidence check

  4. Reconciler

    A strong reasoning model merges findings, traces transitive paths and keeps metadata-versus-text mismatches visible.

    Decisions here:4. Conflict check

  5. Accountable person

    Counsel or the compliance owner decides whether a flagged licence is acceptable and what to replace or disclose.

    Decisions here:5. Person decides

Checked before anything is accepted

  • Every classification quotes the licence text it rests on
  • Declared licence in metadata is compared with the actual file; mismatches are flagged
  • Missing or unreadable licence files are reported as gaps, never guessed
  • Forbidden-licence findings are re-read by a second worker from another family

What comes back

  • Policy violations by package, with quoted clause and dependency path
  • Packages whose metadata and licence text disagree
  • Missing notice and attribution list
  • Packages nobody could classify, with the reason

What to measure

  • Findings confirmed by counsel against findings raised
  • Packages left unclassified
  • Reviewer hours spent on flagged items only
  • Cost per package checked

Names of measures only. No result is claimed for this template.

Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.

Get early accessSign in to use

Migration impact map across services

For: Staff engineer or platform lead planning a framework, database or shared-library migration

A breaking upgrade touches modules owned by many teams.

Pattern: Hierarchical decompositionNeeds a connector6 decisionsDesigned for 30 to 800 agents

Test case tournament for a module that must not break

For: Quality lead or engineer owning a payment, pricing or permissions module with thin tests

The module that must not break has happy-path tests only.

Pattern: TournamentNeeds a connector6 decisionsDesigned for 20 to 300 agents

Design review panel for an architecture proposal

For: Engineering manager or architect taking a design document to review before build starts

Design reviews depend on who shows up.

Pattern: Specialist panelNeeds live models5 decisionsDesigned for 4 to 16 agents