Specification completion audit
This record maps the original BlueTusk product specification and the subsequent
architecture-gap review to concrete repository evidence. “Complete” here means
the engineering surface is implemented, documented, and covered by an
executable gate. All six families were published at 1.0.0 under the
documented owner exception, but this
record does not replace external production experience or declare every
PostgreSQL deployment suitable without application-specific validation. Those
release boundaries remain in Runtime release readiness.
Original product specification
| Specification area | Engineering state | Primary evidence |
|---|---|---|
| 1–5. Vision, layers, repository, package family, and branding | Implemented and published as six layered stable 1.0.0 product families; later publication remains gated. | Architecture overview, layering ADR, roadmap, and the Release packaging gate in CI. |
| 6. Transport | Implemented with genuine sync/async socket and TLS paths, cancellation-safe lifetimes, bounded buffers, and multi-host endpoints. | Transport architecture, transport tests, and TLS tests. |
| 7. PostgreSQL protocol engine | Implemented independently of ADO.NET and EF, including framing, state transitions, extended query, streaming payloads, cancellation, and capture tooling. | Protocol guide, state-machine tests, streaming tests, and fake-server conformance. |
| 8. Authentication and security | Implemented for TLS, channel binding, SCRAM, MD5 compatibility, OAuth bearer, GSSAPI/Kerberos, SSPI, client certificates, password files, and redaction. | Security guide, security tests, and authentication conformance. |
| 9. Server capability model | Implemented from startup/catalogue facts and exposed through physical sessions and ADO.NET connections. | Server-capability implementation, environment integration tests, and SQL/PGQ capability tests. |
| 10. PostgreSQL type system | Implemented with span-based codecs, catalogue-derived identity, arrays, ranges/multiranges, enums, domains, composites, records, geometric/network/temporal/text-search/catalogue types, source generation, and unknown values. | Type-system guide, type-system tests, structured-codec tests, and live codec tests. |
| 11. Extension SDK | Implemented with immutable data-source feature registration, separate ADO.NET/EF plug-ins, compatibility testing, authoring template, and independently packaged extensions. | Extension guide, citext ADO.NET tests, citext EF tests, and template contract. |
| 12–14. ADO.NET, pooling, commands, batches, and prepared statements | Implemented with data-source-owned pools, reset isolation, multi-host selection, typed parameters, transactions, preparation, batches, sequential readers, cancellation, sync/async APIs, and provider-factory conformance. | ADO.NET guide, pooling guide, pool tests, command/session integration, batch integration, and provider conformance. |
| 15. PostgreSQL-native APIs | Implemented for raw and typed COPY, notifications, large objects, and cancellation with failure recovery. | COPY guide, notification guide, large-object guide, COPY integration, notification integration, and large-object integration. |
| 16. Replication | Implemented as dedicated unpooled physical/logical sessions with COPY BOTH, pgoutput, checkpoints, feedback, reconnect validation, ownership documentation, stress, and endurance gates. |
Replication guide, wire tests, pgoutput tests, live replication, and replication stress. |
| 17. EF Core provider | Implemented for EF Core 10 relational services, model building, CRUD, query/update pipelines, data-source integration, runtime UDTs, database lifecycle, and design-time tooling. | EF guide, data-source integration, runtime type integration, CRUD integration, and official specification-test record. |
| 18. PostgreSQL LINQ support | Implemented for the documented operators, functions, aggregates, JSON, arrays, ranges, row values, set-returning functions, data modification, and supported graph composition. | EF query documentation, operator tests, function tests, JSON tests, and query-construct tests. |
| 19. PostgreSQL migrations | Implemented for relational objects plus extensions, collations, partitions, publications/subscriptions, views, routines, triggers, rules, event triggers, foreign data, row security, tablespaces, inheritance, UDTs, and property graphs. | Migration tests, migration integration, and the PostgreSQL-specific migration test projects listed in testing. |
| 20. PostgreSQL 19 property graphs | Implemented behind detected PostgreSQL 19 capability with metadata, migration, reverse-engineering, typed query translation, raw SQL, relational composition, tooling, and an executable sample. | Graph guide, metadata tests, migration integration, query integration, raw SQL integration, and graph sample. |
| 21. Database-first scaffolding | Implemented through provider design services, reverse-engineering tests, schema inspection, generated code verification, and property-graph discovery. | Reverse-engineering tests, design project, and schema inspector. |
| 22. Diagnostics and observability | Implemented with redacted diagnostics, activities, meters, pool/native/replication signals, and integration coverage. | Observability guide, diagnostic unit tests, and diagnostic integration. |
| 23. Testing strategy | Implemented with fake protocol servers, protocol capture, differential tests, official EF specifications, PostgreSQL 15–19, optional-extension images, PgBouncer, locale/time-zone, primary/standby topology, stress, endurance, and nightly PostgreSQL 19 gates. | Testing guide, CI workflow, fake server, differential tests, and official EF suite. |
| 24. Performance strategy | Implemented as end-to-end and isolated benchmarks with checked-in reports, explicit allocation budgets, transport-decision evidence, and paired Npgsql reference workloads. | Allocation discipline, benchmark guide, provider comparison, and transport ADR. |
| 25–29. Delivery, vertical slice, principles, release sequence, and success definition | Engineering milestones are closed and the principles are enforced by tests and CI; stable-release promotion remains an explicit, fail-closed maintainer decision. | Roadmap, release readiness, release process, architecture conformance, and CI workflow. |
Architecture-gap closure
| Priority | Closure evidence |
|---|---|
| 0. Finish data-source EF and runtime UDT work | UseBlueTusk(BlueTuskDataSource) ownership, option switching, service-provider identity/debug metadata, pool reuse, and runtime catalogue mappings are covered by provider configuration, data-source integration, and type-mapping integration. |
| 1. Data-source-first usage | The ADO.NET guide, EF guide, samples, and extension documentation lead with a long-lived BlueTuskDataSource; direct BlueTuskConnection construction is documented as unpooled. Replication derives a dedicated unpooled option snapshot from the data source as shown in the replication guide. |
2. Distinguish pipeline mode from System.IO.Pipelines |
PostgreSQL pipeline mode has explicit synchronization groups, ordered results, error/cancellation recovery, disposal, fake-server, live, conformance, and stress coverage in the pipeline guide, pipeline conformance, and pipeline stress. The separate transport experiment and decision are recorded in ADR 0005. |
| 3. Allocation discipline | Complete command/result, structured-codec, COPY, streaming, replication, EF, and graph paths have checked-in reports and 24 machine-checked budgets in Allocation discipline and the benchmark baseline. Claims exclude inherently owned returned CLR values. |
| 4. Enforce boundaries | ArchitectureDependencyTests enforce the directed project graph and reject ADO.NET/EF leakage into lower layers. The narrow EF/provider seam is documented in the architecture overview; protocol tests have no ADO.NET or EF dependency. |
| 5. Complete the extension seam | BlueTuskDataSourceBuilder.Features builds an immutable registry carried by the data source. Citext is implemented end-to-end for ADO.NET and EF, optional packages remain isolated, and the template plus compatibility harness are executable through the extension guide and template contract. |
| 6. Keep replication first-class | Physical/logical replication and pgoutput remain separate packages and never borrow pooled ADO.NET sessions. Allocation/backpressure, cancellation/disposal, reconnect/checkpoint, PG15–19, stress, and scheduled endurance evidence is catalogued in the replication guide and release readiness. |
| 7. PostgreSQL 19 and SQL/PGQ | Capability detection, live DDL/query/preparation/batch/cancellation/pooling coverage, metadata, migrations, reverse engineering, typed GRAPH_TABLE translation, sample, and tooling are implemented while PG15–18 remain green. Beta-sensitive syntax is isolated and documented in the graph guide. |
| 8. Documentation and release truthfulness | README, roadmap, stable-candidate package versions, support limits, executable evidence, and publication boundaries are reconciled in release readiness. The documentation gate validates every tracked local link on Windows and Linux. |
Real-time platform phased plan
The real-time platform adds a second release train on top of the provider. The engineering state and the release state are tracked separately: passing unit, integration, package, and compatibility gates creates a candidate, while a required real-duration endurance report is the evidence that permits promotion.
| Phase | Engineering state | Primary evidence | Remaining release boundary |
|---|---|---|---|
| 0. Architecture and release groundwork | Implemented. Delivery, checkpoint, snapshot, spool, relay, Live security, and Sync destination decisions are recorded; dependency direction and publication policy are executable. | ADRs 0006–0012, product-family manifest, release process, and product-family architecture tests. | None for the architecture gate. |
| 1. Streams transaction kernel | Implemented for ordinary, streamed, committed, aborted, prepared, and two-phase transactions with explicit tuple state and bounded spooling. | pgoutput stream tests, durable-state tests, and live replication tests. | Included in the Streams release-endurance gate. |
| 2. Checkpoints, leases, groups, and relay | Implemented with monotonic compare-and-swap state, fencing, direct groups, durable PostgreSQL relay, replay, retention, and separate-control-schema validation. | state-store conformance, relay integration, and storage validation. | Included in the Streams release-endurance gate. |
| 3. Typed Streams and snapshot bootstrap | Implemented with typed/dynamic mappings, EF mapping, exported-snapshot restart semantics, CloudEvents, DI, Aspire, CLI, health, telemetry, testing helpers, and all registered packages. | typed mapping tests, snapshot coordinator tests, Streams package manifest, and Streams guide. | Stable 1.0.0 artifacts are published; the deferred exact-candidate evidence remains gated hardening work. |
| 4. Streams hardening and Control Plane foundation | Engineering slices are implemented, including format/API freezes, relay upgrades, operations APIs, dashboard views, and release evidence tooling. | Streams API freeze, Streams format registry, Control Plane API freeze, Control Plane format registry, Control Plane tests, and Streams endurance verifier. | A verified, archived 72-hour report for the exact Streams candidate is still mandatory. |
| 5. Sync 1.0 | The pipeline, all four destinations, conformance kit, transforms, quarantine/replay, reconciliation/repair, rebuild/cutover, hosting, telemetry, Aspire, candidate API freeze, and durable-format registry are implemented. | shared destination conformance, Sync API freeze, format registry, and Sync guide. | A verified, archived 24-hour report for the exact Sync candidate is still mandatory before publication. |
| 6. Live 1.0 | Authorised registered EF plans, gap-free initial delivery, keyed diffing, replay, signed resume, security-scoped sharing, quotas, SignalR, SSE, gRPC, TypeScript, Angular, React, advanced query capabilities, candidate API freeze, and durable-format registry are implemented. | query compiler tests, adversarial/load tests, transport matrix, and Live API freeze. | Live 1.0 cannot be published ahead of its Streams dependency and final release verification. |
| 7. ContinuousGraph 1.0 | Implemented as capability-guarded registered SQL/PGQ plans with dependency-aware invalidation, authoritative GRAPH_TABLE requery/diff, bounded affected-key incremental maintenance with authoritative repair, samples, an optional Control Plane adapter, API freeze, and benchmarks. |
compiler tests, incremental state-machine tests, PostgreSQL 19 integration, API freeze, ADR 0016, and the ContinuousGraph guide. | PostgreSQL 19 GA, the exact 24-hour/100,000-evaluation endurance report, dependency publication, and an independent pilot remain mandatory. |
artifacts/ is ignored by source control because endurance runs contain large
binary and test-result trees. A release gate is complete only after its verifier
accepts the report for the expected source commit and the workflow archives that
report with the release record. A running process, short smoke result, or report
from an earlier candidate is not acceptable evidence.
Current verification snapshot
The final local matrix on 2026-08-02 used the same Release binaries and the CI connection contract across all supported PostgreSQL versions:
| PostgreSQL | Test assemblies | Passed | Intentional skips | Failed |
|---|---|---|---|---|
| 15 | 28 | 2,963 | 147 | 0 |
| 16 | 28 | 2,964 | 146 | 0 |
| 17 | 28 | 2,966 | 146 | 0 |
| 18 | 28 | 2,978 | 146 | 0 |
| 19 Beta 2 | 28 | 2,978 | 146 | 0 |
On 2026-08-17, after the official milestone advanced, the complete serial solution suite was rerun against the digest-pinned PostgreSQL 19 Beta 3 image with zero failures. The table above remains the exact dated 2026-08-02 provider-only snapshot rather than retroactively relabelling that evidence.
The provider audit produced a zero-warning Release build and 31 stable 1.0.0 candidate packages. Its V1 candidate API budget locks 8,308 signatures across 28 API-governed Provider library surfaces, while package conformance excludes embedded template content projects. The current monorepo-wide gate covers 123 solution projects, reports no vulnerable direct or transitive NuGet dependencies, validates every repository-local documentation link, and passes 46 allocation budgets. The two additional solution projects are the non-packable pg_durable preview adapter and its tests. They do not alter the stable Provider package or API totals and cannot be used as production-readiness evidence for upstream pg_durable. The final two-launch provider MediumRun records lower BlueTusk mean latency and managed allocation in all five paired workloads; parameterized scalar, warm checkout, and 1,000-row streaming have non-overlapping latency intervals, while prepared scalar and the 1 MiB stream remain statistical parity despite lower BlueTusk means. Exact values, confidence intervals, workload fairness, and environment details are in the checked-in provider report.
Explicit release boundaries
- Packages are published at stable
1.0.0, but publication and engineering-gate completion do not substitute for the deferred external production experience or independent approval. - PostgreSQL 19 coverage uses the official Beta 3 image plus a scheduled build of the upstream PostgreSQL 19 branch; beta syntax can still change before GA.
- Real-account AWS, Azure, and Google Cloud identity acceptance remains opt-in because repository CI does not hold customer credentials; deterministic SDK contract tests are mandatory and pass without those credentials.
- Bounded statement multiplexing is implemented for data-source-owned, session-neutral commands. Explicit connections, transactions, prepared commands, replication, notifications, and classified stateful SQL remain intentionally session-affine. The release gate includes forced shutdown, cancellation/error isolation, and a direct Npgsql benchmark comparison.
- One tablespace integration case requires a server-owned filesystem directory and is intentionally skipped where that external directory is not configured.