October 1, 2026

A foundation firms can build on

The warehouse combines lessons from several STAR-based products into a shared core. It organizes common WIP, billing, collections, and AR data. It is a starting point for a firm’s own reporting and extensions; it does not claim to include every custom field or every firm-specific reporting rule.

Instead of reproducing STAR’s wide WIP and nominal tables unchanged, the model separates their record types into narrower business tables. Billing headers, billing lines, write-offs, and allocations become easier to find and join. The matching dbsource table-valued functions show how each db table is populated, keeping the extraction and transformation logic open to inspection.

Follow the relationships through billing

Kent’s question about billing allocations led to a diagram of the related tables. A bill can have lines, write-offs, and allocations. Where a reference can point to more than one kind of WIP record, the common WIP identity table provides a parent. This spine preserves a place for those references without pretending every parent belongs to one subtype.

Foreign keys make those relationships explicit and enforce that the referenced records exist. They also give the query optimizer information it can use. Trusted constraints can enable some query simplifications, including elimination of redundant joins; whether a particular join can be removed depends on the query and its constraints. The practical point is to declare the relationships, then inspect the resulting plan.

Keep the source rules visible

The source functions still contain the STAR-specific rules. The walkthrough used billing records with charge type 22 and billing lines with charge types 14 through 18 as examples. Readers of the warehouse can work with named business tables, while developers can inspect the functions to see the rules behind them.

Sample reports accompany the core, but the meeting treated them as examples. A firm should review their definitions against its own practices before treating the resulting figures as its reporting standard.

A progress bill is more than a label

Kent raised progress-bill identification as a difficult case. He and Brad described a bill that initially allocates to itself, then changes as work is applied against it. The remaining balance matters as well as the original bill. That discussion made the allocation history central to understanding the behavior.

The walkthrough followed that question into the warehouse’s billing-allocation table and its documentation. Kent observed that the existing material appeared to address the case and wanted to read it more closely. This was a useful design review, not a completed verification of every progress-billing scenario at every firm.

Rates can carry a different question

Kent also highlighted standard staff rate and standard staff amount as useful context when the applied rate differs, including job-specific rates. Those values help separate the standard-rate comparison from the rate actually used. This was raised as a point to review, rather than demonstrated as a newly implemented warehouse feature.

Both questions reinforce the same requirement: record the business interpretation and the exceptions. A foreign key can prove that two rows relate; it cannot explain the accounting meaning of that relationship on its own.

Relationships show the path; descriptions explain the meaning

The additional step in October was documentation attached to the warehouse itself. The demonstration showed editable descriptions for schemas, objects, and columns. A stored procedure takes that maintained documentation and applies it to SQL Server extended properties.

This gives a tool that reads those properties useful context alongside the schema: what a table represents, what its columns contain, and how the data should be interpreted. The model still needs a way to inspect that metadata. An extended property is information available to a tool, not an instruction that automatically connects every AI application to the database.

Two audiences need different levels of detail

The longer notes beneath the source functions were written for developers. They explain surprises, monetary values and dates, observed behavior, source procedures, assumptions, and example questions. These notes preserve why a particular interpretation was chosen.

The descriptions exposed through metadata were focused on helping an AI choose the right data and generate a query. Keeping the detailed reasoning and the compact descriptions together makes it possible to explain the model to a person and give an agent a practical starting point.

Improve the descriptions by testing what they enable

Amine described using a more capable model to draft descriptions and test questions, then asking a smaller model to generate SQL using only the warehouse metadata. The descriptions were revised until the selected questions passed those checks. The material being improved was the context supplied to the model.

That is evidence about the reported test set, not a guarantee for every future question or a different firm’s configuration. The generated SQL and its results still need review. The session described this testing process; it did not run a live natural-language reporting demonstration.

Inspect the descriptions in SQL

This read-only example lists table and column properties in the warehouse’s db schema. A row without a column name describes the table itself. It lets a developer see the stored information an appropriately configured metadata-reading tool can retrieve.

Keep knowledge available without loading it all at once

The documentation grew out of the second-brain work discussed in September: an organized collection of project information, STAR object research, and knowledge from existing products. An index directs an agent to the relevant material instead of placing the entire collection in every conversation. This was described as progressive disclosure.

Amine described using synthetic identifying data during exploration and using another model to challenge the first model’s conclusions. Unresolved disagreements came back to him for a decision. The warehouse architecture and implementation remained his work; AI helped synthesize the documentation and test the reasoning.

Make assumptions part of synchronization

The source documentation also explains what the refresh process assumes. Different STAR firms can use switches or configurations that change where records appear or how they behave. The warehouse includes validation intended to stop a load when a checked assumption does not hold, rather than quietly carry that mismatch into a report.

A validation failure is information for the firm’s developer to investigate. The goal is to understand the difference and adjust the appropriate rule, rather than discard the check simply to make the load succeed. Custom fields and dimensions remain extensions for the firm to add.

The virtual database supplies a local copy

The warehouse reads the selected STAR tables through a virtual database. It keeps the required columns close to the reporting workload so the warehouse does not repeatedly reach across the network to the operational STAR database.

The source rowversion is retained as binary(8). Incremental synchronization uses that value to identify inserted or updated rows. A separate comparison of key ranges and counts narrows the work needed to find deletions, because a deleted row no longer has a rowversion available to read.

When Kent compared this to CDC, Amine distinguished it as synchronization or mirroring. It maintains the selected current-state copy; it is not SQL Server Change Data Capture and does not promise a history of every row change. It is also separate from the SQL DDL change history demonstrated in September.

The setup order shown in the meeting

The walkthrough described the sequence below. Database names can be chosen for the local environment; the important dependency is that the warehouse’s synonyms point to the intended virtual database.

1. Create the virtual database

Apply its script to create the objects and the configuration describing which STAR tables to copy.

2. Configure the source connection

Create the linked server using the appropriate credentials and set the virtual database configuration to the chosen linked-server name and source STAR database. The linked server can point to a development environment.

3. Create the warehouse synonyms first

Create an empty warehouse database. Use the virtual database’s interface view to generate the synonym statements, then run those statements in the warehouse so they refer to the virtual database name actually chosen.

4. Apply the warehouse script

With the synonyms in place, apply the warehouse objects and their configuration and documentation. The source functions can then resolve the tables they depend on.

5. Load, validate, and schedule

The virtual copy performs a full initial load when no rowversion watermark exists, then uses the configured synchronization mode for later runs. The warehouse refresh checks its configuration and assumptions. Review the resulting data and choose the required SQL Server Agent schedule, refreshing the source copy before its consumers.

Reset helpers belong to development

The demonstration also showed reset procedures that clear copied data, synchronization state, and logs. These support starting over during development; they are not routine refresh commands. Amine advised excluding those reset helpers from production deployments.

The warehouse and virtual-database download is listed on the Resources page. The installation sequence above summarizes the meeting; the script package and the firm’s configuration determine the exact deployment commands.

The proposed next step is a controlled tool loop

The closing proposal was a learning example built around a local language model. A stored procedure would accept a question, supply the model with available actions, interpret a structured request, carry out an allowed action, and return the result to the model. That exchange would continue until the model could answer.

The model supplies text or structured output; the surrounding program decides what to execute. One example was a request for a table’s metadata. The program would validate that request, read the allowed information, and return it. This puts the tool behavior under the developer’s control.

A direction for a future session

A self-contained local model server and a downloaded model file were suggested for the learning setup. Amine explicitly left the timing open: the next month or the month after. This tool loop was a proposal, not part of the demonstrated warehouse release or a confirmed November agenda.

The next regular SQL SIG meeting is Thursday, November 5, at 11:00 a.m. Eastern. Topic suggestions and feedback on the warehouse are welcome.