SpeclyThe same specification answers very different people, because it holds the meaning and not just the table definitions. Your role in the project decides whether you read, suggest changes, edit or administer the setup.
“Do we agree on what ‘active customer’ means before we model it?”
The business glossary gives each term one definition, one technical name and one data type, and links it to every column that means the same thing. As Contributor you suggest changes to descriptions and metadata, and your suggestion is reviewed before it goes in. When several of you work on the same branch, you see each other in the diagram and who is editing what, as it happens.
“Does the model follow the same rules across teams?”
As Admin you define the data types and table types the project builds on, and which custom fields each table type should have. Changes are made in a branch, and you see them side by side with main in a comparison before they are merged. When several of you work on the same branch, you see each other in the diagram and who is editing what, as it happens.
“Which changes are ready for development, and is the spec complete enough to build?”
The statuses your project has set up show where each table stands. As Developer you edit the model in your own branch, and the model lives as files in the Git repo next to the code. Validation against Databricks, Fabric or dbt shows which tables and columns match, differ or are missing.
“Can I change fifty tables from my editor and just keep Specly up to date?”
Yes. The model lives as files in its own Git repo, and each branch in Specly is one branch in the repo. When you make large changes to the files from your editor, with AI if you like, they come back into Specly through a review before they are merged. You work in the files, and Specly shows what they describe.
“Which data product is closest to done – what should we do next?”
A data product groups tables and diagrams into one deliverable, with its own owner and status. The overview shows what is live, what is on its way to production, and what still lacks a description or an owner.
“Which tables hold sensitive data, and who is it shared with?”
Flags such as personal data are set on columns, so you can see which tables hold sensitive data. Every data product has an owner, and the source system shows where the data in a table comes from. As Admin you decide which metadata fields others can suggest changes to.
“What has the platform delivered, and what is coming?”
The overview brings together what is live, what is on its way to production, and who is working in which branches, on one page. As Viewer you see the whole model without being able to change anything by accident.
“What does this field mean, and who can I ask?”
You search across the data platform and find the definition in the business glossary and the owner on the table. As Contributor you suggest a better description when something is unclear, and someone on the team reviews the suggestion before it goes in.
“Table X failed overnight. Who do I notify, and how urgent is it?”
The table shows who owns it and answers for it, so you know who to notify. Lineage shows which tables read from it, and so how far the failure reaches.
Tell us how you work today, and we will show you how Specly could fit in.