What additive expansion at enterprise scale looks like under a merge gate

Findings

0 breaking, 4 additive, 1 flagged as spec hygiene. Each finding cites the exact change-type from the 27-type taxonomy, the surface affected, and the consumer impact. The hygiene finding here is a reconciliation observation about engine coverage on Swagger 2.0 surfaces; we surface it so the reader sees both the engine's pass verdict and the inventory the engine did not enumerate.

1. additivefinding F1
   change type: endpoint_added (1 new path, 1 new operation)
   surface: /v2.1/accounts/{accountId}/envelopes/{envelopeId}/shares (POST EnvelopesShares_PostEnvelopesShares)

   A new POST endpoint landed under the Envelopes surface for delegating envelope access to additional users. The operation accepts an envelopesSharesRequest body (an array of envelopesSharesRequestItem entries, each carrying an agentUser reference and a permission string) and returns 201 with an envelopesSharesResponse, or 400 on a request error. The operation is bracketed by six new component definitions (EnvelopeShares, envelopesSharesRequest, envelopesSharesRequestItem, envelopesSharesResponse, envelopesSharesResponseItem, and docGenFormat). The endpoint is purely additive: no existing path, operation, parameter, or response schema was altered to make room for it. A consumer pinned to the prior surface keeps working without code changes; a consumer that wants to use envelope sharing opts in by adding the new path. This is the textbook shape of a clean enterprise-API surface expansion.

2. additivefinding F2
   change type: optional_field_added (uniform across 11 recipient roles)
   surface: #/definitions/{signer, agent, editor, carbonCopy, certifiedDelivery, inPersonSigner, intermediary, notaryRecipient, notaryWitness, participant, witness}

   A single new optional property, signingGroupType, was added to every recipient-role definition that participates in an envelope. The property is a string, is not on any required list, and the addition is uniform: same field name, same type, same shape, on every one of the eleven recipient roles. An existing client that constructs a signer or witness object without the field continues to validate. A new client that wants to declare the signing-group classification can opt in. The pattern is the disciplined way to evolve a recipient model that already has eleven peer subtypes: change one shape, change all eleven the same way, in the same release.

3. additivefinding F3
   change type: optional_fields_added plus property_renamed (case-only)
   surface: #/definitions/accountSettingsInformation

   The accountSettingsInformation schema, which carries roughly 1,500 settings flags for an account, gained nine new optional properties and lost four. The additions cover Bring Your Own IDV (allowBYOIDV plus its metadata sibling), two FedRAMP IDV level flags with metadata, two Navigator hierarchy AI flags, and a pluralized enableSigningAIFeaturesPlan. The removals are all four legacy settings adjacent to that last addition: an upper-case EnableSigningAIFeaturesPlan that was renamed lower-case (a same-shape, same-type, casing-only rename), the older enableSigningAIFeaturesSetting plus its metadata sibling that the new Plan flag supersedes, and an internal experiment flag whose name encodes a feature ticket. None of the removed properties were on the required list, so the diff engine does not classify the removal as breaking. A client that read the upper-case Plan field will need to read the lower-case one; a client that read the experiment flag will see undefined. Both cases are intentional cleanup of an enterprise settings surface and the visibility of the rename in the attestation is itself the artifact.

4. additivefinding F4
   change type: optional_fields_added (3 new properties on a document-generation field)
   surface: #/definitions/docGenFormField

   The docGenFormField schema, used by the document-generation surface to describe sender fields embedded in templates, gained three new optional properties: format (a $ref to the new docGenFormat definition that carries an expression and a locale), hidden (a string flag), and readOnly (a string flag). All three are absent from the required list. Existing template definitions parse against the new schema unchanged; new template definitions can opt into the locale-aware format expression and the hidden / read-only state flags. The field-level expansion is paired with the new docGenFormat definition, which is the only new definition in the window not directly tied to the envelope-shares endpoint.

5. spec hygienefinding C1
   change type: engine_under_classification (manual reconciliation surfaced)
   surface: spec-wide (paths, definitions, properties)

   The diff engine, run in its standard configuration, classified one change in the window: the new envelope-shares endpoint. A manual reconciliation walked the same two specs and surfaced twenty additional surface deltas: six new component definitions, sixteen new optional properties spread across thirteen modified shared definitions, and four removed optional properties on the account-settings shape. None of the manual deltas reach the breaking threshold, so the engine pass is correct in its decision; it is narrower in its inventory because the v2 OpenAPI diff engine is tuned tightly for OpenAPI 3.x patterns, and Docusign publishes Swagger 2.0. We surface this as a hygiene observation so the reader sees the full delta and the limit of what the engine reports today, not just the wire-shape verdict. The engine roadmap closes this gap; the visibility of the gap is the artifact this report was written to make legible.

What this report is not

Not a defect claim. Not a security advisory. Not a judgment of the Docusign team's release process. Docusign ships an enterprise SaaS API with active customers across regulated industries; the eSignature v2.1 surface is the long-running stable contract those customers pin against. The changes flagged above are the textbook shape of additive enterprise-API expansion: one new endpoint, six supporting definitions, a uniform property added across eleven peer recipient roles, and a settings-surface cleanup that retires two legacy flags and renames a third to consistent casing. The merge gate shipped a clean pass and a minor-class semver recommendation, and both reflect the actual shape of the diff.

The findings above do not say Docusign did anything wrong, and they do not say Docusign did anything special either. They say: here is exactly which endpoint, which definitions, and which properties shifted in 46 days, here is the uniform pattern across the eleven recipient roles, here is the settings-shape rename, and here is what stayed identical (zero breaking changes, every existing endpoint preserved, every existing required field preserved). That visibility is the artifact. A downstream consumer who reads this attestation knows their pinned client will keep working without re-running the analysis, and an auditor knows exactly what shipped without taking anyone's word for it.

The attestation artifact

A Delimit attestation is a bounded evidence record at a single commit pair. The same Delimit version run against the same two commits produces the same bytes; that is the replayable property. The attestation does not opine on whether a change should have shipped, only on what shipped and how the change-type taxonomy classifies it. A pass is as much an artifact as a fail; both are evidence that survives the moment.

For the precise list of checks, the explicit out-of-scope list, and the reproducibility guarantee, see the attestation methodology v1. This report is the OpenAPI-diff surface of the same primitive that powers the merge gate for AI-written code.

Reproduce locally

Anyone can re-run the analysis above against the same two commits and verify the same diff comes out. The full command sequence:

# Install the CLI
npm install -g delimit-cli

# Clone the repo (full history; we walk back ~46 days)
git clone https://github.com/docusign/OpenAPI-Specifications
cd OpenAPI-Specifications

# Extract the two specs at the cited commits
git show 2ce9d65:esignature.rest.swagger-v2.1.json > /tmp/old.json
git show f6e8d4a:esignature.rest.swagger-v2.1.json > /tmp/new.json

# Run the merge gate
delimit lint /tmp/old.json /tmp/new.json

If the bytes you get differ from the bytes in this report, that is itself a finding worth reporting; raise it on the Delimit repo and we will look. Each spec is roughly 4.6 MB; the lint pass completes in well under one second on a standard laptop.