Generated is not the same as verified

Code generation proves that a template produced files. It does not prove that a developer can install the result, authenticate, make a request, page through a collection, recover from an error, or reproduce the package later.

For an SDK to be a product, verification has to cover more than syntax.

Doctorine currently generates and verifies configured TypeScript, Python, and Go artifacts. Each target has its own language conventions, but the release model asks the same question: what evidence shows that this artifact is fit to deliver?

Start with a deterministic API model

An SDK pipeline inherits every ambiguity in its input.

The first layer is a validated, canonical representation of operations, schemas, authentication, pagination, and errors. Diagnostics need to point back to the author’s actual file and position. A stable bundle identity makes it possible to determine whether two builds started from the same technical source.

This layer does not make an SDK good by itself. It makes the next layers explainable.

Treat runtime behavior as owned code

The generated methods are only one part of a usable client. Runtime kernels implement behavior that should remain consistent across services and releases:

• request construction and authentication;
• retries, timeouts, and cancellation;
• error normalization;
• pagination;
• serialization and response handling;
• user-agent and package metadata.

These kernels should be reviewed and tested like any other library code. Hiding them inside ad hoc templates makes defects harder to isolate and fixes harder to propagate.

Doctorine keeps language-specific kernels for TypeScript, Python, and Go, then generates the API layer against them.

Run the language’s real build

A file tree can look plausible and still fail the first command a developer runs.

Verification should execute the configured target’s own checks. Depending on the language and package, that includes compiling or type-checking the generated source, running owned kernel tests, and validating the package shape expected by the build.

The exact check matters less than one principle: the artifact offered to a customer should be the artifact that passed—not a second untracked regeneration created afterward.

Verify behavior that templates cannot see

Static generation catches structural problems. Behavioral tests catch contract mistakes between the generated layer and runtime.

High-value cases include:

• authentication headers and token placement;
• retry decisions for safe and unsafe requests;
• pagination termination and next-page construction;
• unknown fields and nullable values;
• error payloads that differ from the happy path;
• path, query, and body serialization;
• cancellation and timeouts.

Property tests and golden corpora can help prove determinism and broad input handling. They are not a substitute for live-endpoint checks when a wire protocol or signing scheme depends on external behavior.

Attach provenance to the downloadable result

Verification without identity is hard to use in support.

A release receipt should connect:

• the source revision;
• the canonical bundle identity;
• SDK configuration;
• target language and package version;
• verification outcome;
• artifact hash and storage identity;
• the release that made the artifact available.

This lets a team answer “Which Python package did this developer receive?” without reconstructing the build from logs and assumptions.

It also makes rollback and reproduction more honest. A previous artifact remains a named result, not merely an old zip file in a bucket.

Keep publishing claims precise

Producing a verified artifact is different from publishing it to npm, PyPI, or a Go module path under a customer’s credentials.

Doctorine’s hosted SDK factory creates verified, downloadable artifacts and records their provenance. Registry publication is a separate operational decision and is not implied by the generation pipeline.

That boundary helps teams decide where release credentials, approval, signing, and distribution should live.

Ask for evidence, not a language count

A long list of generated languages is easy to market and expensive to support well.

When evaluating SDK delivery, ask for one configured target and follow it end to end:

1. Which input and configuration produced it?
2. Which runtime behavior is owned and tested?
3. Which language-native build ran?
4. Which exact artifact passed?
5. What provenance is available after download?
6. How does the team reproduce or roll back it?
7. Which publication steps remain outside the platform?

Three well-supported targets can create more developer trust than twenty template outputs with no operational evidence.

See the Doctorine SDK verification model.