Source every suggestion at the moment it is offered — the model, its version, the filter settings and the hunks kept — then hold the change for the named engineer who commits it.
A completion is offered, and the model, its version and the filter settings go down beside it.
02
A commit is signed by a person, and the machine origin beneath that signature stops being visible.
Reason
03
A hunk is machine-written, and copyright does not reach that portion standing alone.
04
A registration is prepared, and 88 FR 16190 asks which content is AI-generated and excluded.
05
A routine is reproduced, and GPLv2 § 2(b) reaches the whole work it was distributed inside.
Decide
06
A licence claim is pleaded in contract, and in Doe v. GitHub the contract claims are what survive.
07
A filter setting is changed, and a vendor indemnity condition can turn on that single setting.
Out
08
A diligence team asks who wrote a file, and the git history answers with a human name.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Suggestion, provenance and the record belong to the agent. The commit belongs to a named engineer, who takes the change into the product and owns it there.
Example workflow
One suggestion, offer to commit
AgentHuman
1Editor request receivedAn open file, a diff under review, a failing test or a pull-request comment
2Context and provenance assembledThe branch, the file, the model and its version, the filter settings and the licence rules configured
3Suggestion producedThe hunk, the resemblance flags, the provenance record and confidence
4Controls appliedLicence-resemblance checks, filter-setting checks, secret checks and confidence
No human action required
Stages 1 to 4 run unaided, and nothing is committed at any of them — the agent is suggesting, and the engineer lane opens at the confidence gate.
5DecisionSplits at the confidence gate
Provenance clean
Goes to the named engineer to commit.
Anything flagged
Adds a code-owner read first.
Engineer review
The hunk is held with its provenance, its resemblance flags and the confidence.
Commit · Amend · Send to code-owner review
Committed — by a named engineer▼
6Repository and forge records updatedOnly where write access and branch policy allow it
7Outcome evaluatedAcceptance rate, amend distance, resemblance-flag outcomes and post-merge defects
Amendments
Each engineer amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Placing a suggestion into the repository.
Deciding that a flagged hunk is safe to ship.
Accepting a licence obligation on the codebase.
Changing a vendor configuration an indemnity rests on.
Automation boundaryAgent acts unaided
✓Draft the hunk from the file open in the editor.
✓Record the model, its version and the filter settings.
✓Flag a suggestion that resembles a source under a known licence.
✓Hold the flagged hunk for the engineer who will sign the commit.
Nothing enters the repository except by a named engineer, inside the agreed boundaries.
Signing an IP representation in a transaction.
Deciding what a copyright registration discloses.
Saying that a review was substantive.
Changes to the SDLC policy or automation thresholds.
Example output
One suggestion, annotated
The PLC automation copilot in manufacturing drafts industrial control logic to a controls standard; this one suggests general application code, and the question it raises is who owns what came back.
Suggestion output · single hunkIllustrative example
Suggestion
Recorded as
Repository
Evidence of record
Confidence
Held for
Retry loop with exponential backoff
Stamped with model and version
Payments service, main
Editor session, 3 August 2026
Held uncommitted
The named engineer, by name
As receivedTaken from the open file and the rules set for that repository, and it claims nothing beyond them.
What the record holdsModel and versionFilter settingsHunks kept
Why no commit hereTaking a suggestion into the product is a judgement an engineer makes.
ActionCommitAmendSend to code-owner review
What the score decidesBelow the configured threshold a hunk gets a code-owner read before the engineer sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each suggestionFrom the branch it was read on
03Provenance
Which rules reach a copilot
Biometrics, infrastructure, education, employment, essential services, policing, migration, justice — the Annex III areas, and a coding copilot is in none of them.
01Approved path
Whose code is this now
Registration requires a human author, and Thaler v. Perlmutter, No. 23-5233, decided by the D.C. Circuit on 18 March 2025, went unreviewed when certiorari was denied.
02Human review
What was checked, and not found
No statute found requires source code to be reviewed before it is committed, and none requires a record of which lines a machine wrote; the nearest binding instrument is PCI DSS 6.2.3, a card-brand contract. What answers a claim years later is that record, or nothing.
04Build an evidence trail
The suggestion, the source it resembles and the developer who committed it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Editors and IDEsVS Code · JetBrains · Neovim Editor and language-server hooks
Source forgesGitHub · GitLab · Bitbucket Pull requests and branches
Vendor and model settingsFilter modes · duplicate detection Configuration and change history
Agent
Code generation and review
Reads the branch Suggests the hunk Holds for the engineer
Scanning and policyLicence scanners · SAST Licence, dependency and secret findings
Integration availability depends on the client's existing systems and API access.
Agent controls
Six sieves between the model and the commit
Six sieves in one column, the last the finest. What settles is drawn in the map below.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeOffer no completion when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, filter-setting and licence-rule changes, and note which version produced each suggestion.Track
L4TraceabilityRecord the suggestion, its model and version, the filter settings, the hunks kept and the commit it entered.Record
L3Engineer commitHold the hunk for a named engineer; the hold governs release, not whether the code is right.Gate
L2Licence guardrailsTest each suggestion against the configured licence rules; a trip returns the hunk, and paraphrase is not what this catches.Restrict
L1Confidence thresholdsRoute a flagged or low-confidence hunk to a code-owner read before the engineer sees it.Require review
Model coreSuggestion produced — the hunk, its provenance, resemblance flags and confidence
L1 – L2Test whether a hunk may stand
L3Leaves the commit to a named engineer
L4 – L5Keep the commit and the suggestion behind it
L6Offers no completion at all when signals degrade
How Nestack evaluates it
Evaluate the whole suggestion path — not only the hunk that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the code that ships in the product
Depth of coverage ▼
E1Final-output evaluationDid the suggestion record the model and settings it was actually produced under?
E2Step-level evaluationDid the agent read the right branch, the right file and the live licence rules?
E3Tool evaluationDid it read and write the correct repository and the correct file?
E4Confidence calibrationDo low-confidence suggestions actually attract more engineer amendments?
E5Slice evaluationHow does performance change across specific repository classes?
E6Business outcomeHow many suggestions needed an amendment before the engineer committed?
Floor — the codebase the company must defend
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed where it first becomes visible.
Agent lifecycleDirection of processing →
01 · Retrieval1 mode
QR-03
Stale branch context
The file read is not the one now on the branch.
Stage gathersThe branch, the file, the model version and the rules
02 · Reasoning2 modes
QR-04
Resemblance missed at drafting
A suggestion echoes a source no rule matched.
QR-06
Retired setting read as live
A superseded configuration is worked as current.
Stage proposesThe hunk, its provenance and the flags
03 · Tool / write2 modes
QR-02
Thin suggestion passed forward
A hunk moves on without the code-owner read.
QR-05
Hunk bound to the wrong change
The record is filed against another commit.
Stage writesOnly where write access and approval policy allow it
04 · Output1 mode
QR-01
Committed, provenance detached
The commit stands but the suggestion under it does not.
Stage returnsThe code the engineer commits and then ships
05 · Change / Version1 mode
QR-07
Silent filter drift
A setting changes while the stored record keeps the old one.
Stage tracksModel, prompt, filter settings and licence rules
Sev-1 · a commit with no provenance behind itSev-2 · a flagged hunk reaches the productSev-3 · signals degrade, suggestion withheld
A repository-level provenance figure can read clean while suggestions against unfamiliar APIs carry most of the amendments. Nestack reports the amendment rate by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Unfamiliar third-party APIs
14.1%
3.7×
Review
Cryptography and auth code
10.0%
2.6×
Review
Legacy modules without tests
6.3%
1.7×
Watch
Routine application code
2.9%
0.8×
Normal
Bar: amendment-rate lift vs. routine-application baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a signed commit conceals
A cycle ends when the copied hunk nobody can source is a standing case. That suite is what the next suggestion accepted is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises on unfamiliar third-party APIs.
02Diagnose
The function that arrived complete, from somewhere, under a human name is worked backwards until one source is left standing.
03Improve
The change ships numbered, and the commits that forced it ride with it.
04Verify
One provenance case still failing is enough to hold the release back.
05Learn
It is kept for good, and the suggestion rules are amended in the same commit.
Learn → DetectThe return edge. The next suggestion is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, suggestion workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Code-review workflow and automation-boundary scope.
02Editor, forge and scanner assessment.
03Licence-rule mapping and filter-configuration capture.
04Suggestion-record capture.
05Provenance and hunk binding.
06Resemblance scoring and review routing.
07Engineer commit workflow.
08Editor and forge integration.
09Provenance and review cases.
10Guardrails and suggestion controls.
11Commit-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne repository, one teamProductionProduction engineering workflowAdvancedMultiple repositories / teams
Introduced at Pilot
Suggestions to your licence rules✓✓✓
Named engineer commit✓✓✓
Repository-provenance baseline✓✓✓
Introduced at Production
Reporting by suggestion class—✓✓
Code-owner review workflow in your forge—✓✓
Approved write-back—✓✓
Editor-and-forge integration—✓✓
Introduced at Advanced
Multi-licence rule sets——✓
Multi-stage code-owner approvals——✓
Large monorepos——✓
Multi-repository suggestion controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, repository volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live repositories and the licence rules each is held to→Provenance capture and suggestion-record versioningWeek 1
02Representative branches, diffs and review history→Suggestion binding, licence rules and the provenance baselineWeek 2
03Your release calendar and the engineers it names→Licence-rule mapping, filter capture and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Editor, forge and scanner assessment, then integration setupWeek 2
05Commits you would not want traced→Source cases and the failure-mode roundWeek 4
06What no suggestion may carry→Resemblance scoring, review routing, guardrails and release controlsWeek 3
07A named engineer who commits the change→Release to the named engineer, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
These bands are counted, not spaced for looks; the fifth week carries two because those two coincide.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Repository workflow discovery, licence-rule mapping and the automation boundaryW2Editor and forge integration and the provenance baselineW3Suggestion workflow, confidence logic and commit controlsW4Evaluation suite, source cases and failure-mode testingW5Forge integration, pilot repositories and targeted correctionsW6One release cycle run under the code owner, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6When the commit record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a code-generation agent around the provenance your last commit never recorded.
Show us one repository and the last release cut from it. What the company owns is the human expression in that code and the trade secret around it, and neither answers a question about which lines a machine wrote. Provenance is cheap at suggestion time and unrecoverable later.
