This route decides how a sentence spoken in a meeting becomes a table in gold — and how it gets refused when it cannot. Three artefacts do the work: an intake short enough that people actually fill it in, five feasibility questions asked in a fixed order, and a link between the requirement and the object that satisfies it that survives both of them leaving the company.
Stand 29.07.2026
Intake
The request arrives as one sentence in a meeting. Everything expensive that follows is decided by how much of the rest gets written down in the next twenty minutes.
Seven fields, one screen, filled in during the meeting. It is deliberately shorter than the template the client already has, because a form nobody completes is not a control — it is a folder.
The intake, with a worked request (REQ-118)
Field
What it must contain
REQ-118
1 · Requester + owner
two names; the owner is whoever signs the number off
requester: Head of Sales DE. Owner: Finance Controlling.
2 · The question
one sentence, worded as the report title would be
Monthly revenue by customer segment and country, DE / AT / CH / NL.
3 · Decision it changes
what somebody does differently depending on the answer
the quarterly segment-discount review, run today off a spreadsheet.
4 · Grain, slices, as-of
one row per what, sliced by what, and as of when
one row per month × customer_segment × country; segment as of the order date, not today.
5 · Measure definition
the arithmetic and the edge cases, citing the business rule
SUM(amount_eur) excluding status = 'CANCELLED' (rule 1); amount_eur already converted at the order-date rate (rule 2).
6 · Source + freshness
which objects, and how late is too late
gold.fct_order_line + gold.dim_customer; loaded daily by 07:00 CET; month closes on working day 3.
7 · Acceptance test
a query, a number, and who runs it
the query below; the June 2026 total agreed with Finance to the cent; the requester runs it.
Field four does most of the work, and field seven is the one that turns the rest into something checkable. Write the acceptance query during intake, against whatever exists today, even if it returns nothing:
sqlREQ-118 acceptance test — agreed before build, run by the requester
-- Rule 1: revenue excludes CANCELLED.
-- Field 4: customer_segment AS OF the order date.
SELECT
DATE_TRUNC('MONTH', f.order_ts) AS month,
c.customer_segment,
c.country,
ROUND(SUM(f.amount_eur), 2) AS revenue_eur,
COUNT(DISTINCT f.order_id) AS order_count
FROM gold.fct_order_line f
JOIN gold.dim_customer c
ON c.customer_sk = f.customer_sk
AND f.order_ts >= c._tech_valid_from
AND (c._tech_valid_to IS NULL OR f.order_ts < c._tech_valid_to)
WHERE f.status <> 'CANCELLED'
AND f.order_ts >= TIMESTAMP '2026-06-01'
AND f.order_ts < TIMESTAMP '2026-07-01'
GROUP BY ALL
ORDER BY month, customer_segment, country;
-- The other reading of the same sentence -- segment as of TODAY -- is
-- ON c.customer_sk = f.customer_sk AND c._tech_is_current
-- and returns a different number. Field 4 exists so that choice is made once,
-- by the owner, and not by whoever writes the join.
Why here
Intake is not paperwork. It is the only moment when a definition problem costs nothing to fix. Most the numbers do not match incidents in a warehouse are not bugs — they are one measure defined twice, once in the pipeline and once in someone's head, and both definitions are defensible.
Field three is the one that kills work, which is why it earns a place on a seven-field form. A request with no decision behind it becomes a report that is opened twice, maintained for four years, and included in every migration because nobody can prove it is unused.
Doing it
Fill the form in the meeting, out loud, with the requester watching your screen. Emailing the template gets it back in three weeks with fields four and five empty.
Write and run the acceptance query during intake, even against an empty gold — running it proves the objects and the join are agreed.
Force the as-of decision explicitly whenever the request touches an SCD2 dimension, and record which reading was chosen.
Restate the measure in your own words and wait. There is always a correction, and it is always cheaper now.
Issue the requirement ID before anyone leaves the room; every branch, PR and table tag downstream references that string.
Embedding it
Have an engineer run the next intake with you in the room and silent unless asked. They run the one after alone.
Back the team the first time they refuse an incomplete intake, in front of the requester. Whether the form is real is decided that afternoon, once, permanently.
Ask 'what gets decided differently?' in refinement until somebody else asks it before you do.
Have the team keep the list of requests that died at field three. At the next steering meeting it is a stronger argument for the process than any slide you could write.
Defaults
Seven fields, one screen, completed in the meeting — not sent as homework.
The acceptance test is a query and a number, agreed before a line of build.
Measure definitions cite the business rule number instead of restating prose per ticket.
Every requirement has one named human owner. 'The business' is not a name.
Gotchas
'Segment as of today' versus 'segment as of the order date'. Both joins are correct SQL and they return different revenue. The divergence grows silently as customers move segment, and it surfaces months later as a trend chart that restates itself — which reads exactly like the business changing.
An acceptance test written after the build. It is then written against what was built, passes by construction, and proves only that the code does what the code does.
Field five answered with 'revenue, the usual'. Rule 1 (exclude CANCELLED) and rule 2 (the rounding in amount_eur) are precisely the 'usual' on which finance and sales differ by a few percent — enough for the report to be disbelieved once and then never trusted again.
Skipping field six because latency 'is a technical detail'. A daily 07:00 load against a request that assumed intraday is discovered in UAT, by the requester, in front of their own stakeholders.
Feasibility, in order
Five questions, cheapest first. The order is the technique: three of the five can kill a request outright, and asking them out of order is how a sprint gets spent building something the data-protection officer was always going to veto.
Each question has an owner, a cost, and a meaning when the answer is no. None of them is 'is it hard?' — difficulty is an estimate, not a feasibility gate.
Asked in this order, every time
#
Question
Answered by
Cost
What 'no' means
1
Does the data exist in any source system at all?
the source owner, in a message
minutes
this is a source project, not a warehouse project — it leaves your backlog today
2
Does it reach us at the grain and latency the request needs?
the bronze table and the job schedule
an hour
a new feed or a cadence change: costed, scheduled, and dependent on someone else
3
Does the source carry the history the question needs?
the extract's specification — not its contents
a morning
frequently fatal, always a surprise; see bronze.sap_kna1 below
4
Do the keys survive conformance across sources?
profiling the join
a day
the answer stays per-source until someone makes an identity decision
5
Is anyone allowed to see it?
the classification and the access policy
a week — it involves people outside the team
a masked or aggregated version of the request, or nothing
Cheapest disqualifier first, with one exception: if the request names a column classified as personal data — dim_customer.email, .phone, .street — ask question five first. It is the only one of the five whose answer is not yours to give, and the only one that can be reversed by someone who was not in the room.
Why here
The expensive mistake is symmetrical. Refusing something feasible sends the work to a spreadsheet you will never see again; accepting something infeasible spends a sprint and then costs the credibility you needed for the next three.
A fixed order makes 'no' a position in a sequence rather than an opinion. Question three failed, here is the probe I ran, here is what the source does not record. That is a sentence a junior engineer can say to a stakeholder; 'I don't think we can' is not.
Doing it
Run the five in order, out loud, with the requester present. The sequence is the argument.
Timebox each: question one is a message, question five is a meeting. Two days into question three IS the answer — the history is not there.
Record which question failed on the requirement itself. In six months nobody remembers whether it was a source problem or a governance one, and the request comes back.
Jump straight to question five whenever email, phone or street appears in the request.
Embedding it
The team runs the five; you hold the clock. Any question that overruns its box is itself a finding worth discussing.
Make them ask question one of the source owner directly rather than routing it through you — that relationship is part of the handover, and it does not transfer at the end.
Walk one feasible request through all five so the team sees the sequence when the answer is yes. A team that only ever sees it applied to refusals learns it as a rejection ritual and quietly drops it.
When they reach question five, hand the conversation to the data-protection owner in front of them. The lesson is that this answer has an owner, and it is not an engineer.
Defaults
Fixed order, cheapest first; anything naming personal data jumps to question five.
Every failed question is recorded with its evidence, not summarised as 'not feasible'.
Feasibility ends in three options, never in a verdict.
Question three is asked about semantics, question four about data — do not swap them.
Gotchas
Answering question one by looking in the warehouse. The warehouse shows only what was already ingested, so you get a 'no' that actually means 'not yet' and a viable request dies of a lookup.
Profiling data to answer question three. A snapshot source looks history-rich — many rows per customer — while the thing being asked for, when and why it changed, is not in there at any row count.
Question five answered by an engineer. 'We can mask it' is true and is not the same statement as 'you may have it'. The engineer's yes gets quoted back six weeks later by someone who never spoke to the data-protection owner.
Treating question four as a modelling task instead of a feasibility one. If SAP customers and webshop customers share no resolvable key, no amount of dimension design produces conformed revenue — and that is a finding for the intake, not a ticket for the sprint.
REQ-118's field four already asked for segment as of the order date, and the owner's follow-up makes the dependency explicit: show me when customers moved between segments, and how many moved last year. Both readings need the same thing — a history of segment changes — and both are bounded by the same source. That source is bronze.sap_kna1, the SAP customer master as a daily full extract with no change timestamp. Nothing in the file says a change happened; the change is the difference between two files.
Answerable: that a customer's segment differs between two extracts we hold — to a resolution of one day, forward from the first snapshot retained.
Not answerable: anything before that first retained snapshot. No engineering recovers it, at any budget. The information was never sent.
Not answerable: a change that happened and reversed between two extracts. A → B → A over a weekend is, to this source, no change at all.
Silently misdated: a change on a day whose extract never arrived is dated to the next extract we hold, and nothing marks it as approximate.
Before promising anything, run the probe. It reads _tech_extract_date — the fourth technical column this source carries beyond the standard three, the extract's business date parsed from the filename by the Ingestion job. It takes a minute and it converts the estimate from a hope into a date:
sqlThe feasibility probe — run during intake, not during build
-- How far back can this source answer 'when did it change'?
-- _tech_extract_date is the extract's BUSINESS date, taken from the filename.
-- _tech_loaded_at would answer a different question -- when we loaded it --
-- and would move every answer on the day the extracts are re-run.
SELECT
MIN(_tech_extract_date) AS earliest_snapshot,
MAX(_tech_extract_date) AS latest_snapshot,
COUNT(DISTINCT _tech_extract_date) AS snapshots_held,
DATEDIFF(MAX(_tech_extract_date), MIN(_tech_extract_date)) + 1
- COUNT(DISTINCT _tech_extract_date) AS missing_days
FROM bronze.sap_kna1;
earliest_snapshot is the honest start of the answer. missing_days is the honest caveat: each missing day is a day on which a real change gets stamped with the wrong date, invisibly. If the probe returns 2026-03-14 and four missing days, the sentence you owe the requester is 'from 14.03.2026, to the day, except across four days where the date may be late' — not 'partially'.
Building it, once an option is chosen, is the snapshot-comparison pattern in the Ingestion route. This route only decides what may be promised.
Why here
This question gets skipped because the table looks rich: a year of rows, one per customer per day. Grain is not history. A year of states and a year of changes are different things, and the request lives exactly in the gap between them.
Skipping it does not cost a sprint — it costs the engagement's credibility. You promise a churn number, build the pipeline correctly, and deliver a chart that starts in March to a business that asked about last year. Everything you did was right and the deliverable is still wrong.
Doing it
Ask the source team for the extract's specification, not a sample. A sample cannot tell you whether a change timestamp exists.
Run the probe before the estimate. Quoting a history start date you have not queried is how the March boundary becomes a surprise in the demo.
State the limitation as a date and a count, in the requirement, in the requester's language.
Record intra-extract reversal as a known limitation — it is invisible by construction, so it will never be found later by testing.
Embedding it
Hand the team the probe and the request and let them find the March date themselves. Being told the source has no history is forgettable; watching MIN() return a date three months ago is not.
Have the team member who found the limitation write the sentence to the requester. Delivering a limitation is the skill being transferred, and you cannot transfer it by doing it for them.
Ask 'what does this source not know?' at every new-feed refinement until somebody answers before you finish the question.
Ask the same question of bronze.sap_vbak and let them find that there is nothing to probe: CDC carries a change timestamp per record, so question three is settled from the extract's specification in a minute. Contrast is what makes the distinction stick — one source needs a query to find its limit, the other has none to find.
Defaults
Interrogate the source's semantics before its contents.
Every promise about history cites a queried date, never an adjective.
Limitations that follow from the source live on the requirement and later in the table COMMENT.
Snapshot sources make bronze retention a correctness requirement, not a storage preference — say so at intake, because it is a cost.
Gotchas
'We have a year of data' offered as the feasibility answer. It is a year of states. The request wanted changes, and the two coincide only where the source records a change event — which this one does not.
Deriving the change date from _tech_loaded_at instead of the extract's business date. Re-running last month's extracts on a Friday stamps every change that Friday, the report shows one enormous migration day, and every job was green.
Promising a backfill from the source archive before anyone has opened it. Archives are routinely incomplete, differently formatted, or kept for thirty days — all of which you discover after the commitment, not before.
Treating missing_days as an operations problem to fix later. For this request it is a correctness caveat owed to the business now, because the misdating is silent and no downstream test can detect it.
'Not possible' ends the conversation and moves the decision to whoever says yes next — usually a spreadsheet. Replace it with three options: what we can do now, what we could do with someone else's help, and what it would take to answer the question properly. Each carries a cost, a dependency, and the part people omit: what it still does not answer.
REQ-118's history problem, as three options
What you get
Cost
Depends on
Still not answered
A · compare snapshots forward
segment changes to the day, from the first retained extract
~2 days, this sprint
nothing outside the team
anything before that date; reversals inside one extract interval
B · request change documents from SAP
true change dates including history, back to SAP's own retention
1 day our side, 4–8 weeks lead time
the SAP team's backlog
nothing — if it arrives, and it arrives later than anyone plans for
C · reconstruct from the extract archive
possibly several extra months of history
1 sprint, quality unknown until it is opened
the archive existing and being complete
whatever the archive lacks — and you find that out at the end
Present all three, name your recommendation, let the owner choose, and write the choice into the requirement including the two that were rejected. In month nine somebody asks why the history starts in March, and the answer has to be a decision with a name and a date on it.
Why here
A flat refusal is heard as the platform cannot do this. It does not stop the report from being built — it stops the report being built where you can govern it, test it, or find it during the next audit.
Three options also move the trade-off to the person who owns it. Whether four weeks of waiting is worth a year of history is a business decision, and every time an engineer makes it silently the business later discovers it was made and resents both the choice and the process.
Doing it
Never present fewer than three, and never pad to three with an option you would not take. A straw option is spotted instantly and it costs you the credibility of the other two.
Cost in days and dependencies, not in t-shirt sizes. 'Large' is not a number anyone can plan against.
State what each option still does not answer. That is the sentence people quote back to you, correctly, in six months.
Recommend one. Three options with no recommendation is abdication wearing the costume of neutrality.
Write the decision, the date, the decider and the rejected options into the requirement before the meeting ends.
Embedding it
The engineer who found the limitation presents the three options, with you in the room and quiet. Whoever finds the problem should carry the conversation.
Rehearse five minutes before: ask what option C costs. If they cannot say, the option is not real yet and the meeting will expose that.
Ban 'not possible' from stand-up. The replacement phrase is 'not from this source — three options', and the team will start using it on each other first.
When the business picks the cheap option against your recommendation, write it down and move on visibly. The team is watching to learn whether disagreeing with a stakeholder is survivable here.
Defaults
Three real options, honest costs, one stated recommendation, one written decision.
Every option names what it still leaves unanswered.
Rejected options stay on the requirement — they are the answer when the same question returns next year.
Anything depending on a third party is quoted as a lead time, never as an estimate.
Gotchas
The straw option. Padding to three with something obviously unserious teaches the room that the exercise is theatre, and the next set of options gets read as sales material.
Costing option B at one day because your part is one day. The SAP team's queue is the schedule; a plan that quietly assumes otherwise slips in public, and it slips at the demo.
Options with no recommendation. The business picks the cheapest, hits its limitation, and feels misled — correctly, because you already knew which limitation they were choosing.
Letting the chosen option live only in a slide. The chart's history starts in March forever, and whoever inherits it treats March as a bug and re-investigates the whole thing from scratch.
From requirement to table
Two objects with different lifetimes, and one link that has to survive a backlog migration, a table rename, and both original humans leaving.
A requirement and an issue are not the same object. The requirement is owned by the business owner, states the question and the acceptance test, and lives as long as the report does. Issues are owned by engineers, close, and there are several per requirement. Collapsing them into one ticket is what produces a closed ticket describing a table nobody can justify.
Intake — seven fields complete. The requirement does not exist until they are.
Feasible — five questions run, the failing one recorded with its evidence, three options presented, one chosen and signed.
Specified — the acceptance test runs. Returning the wrong number is fine at this stage; failing to execute is not.
In build — one or more issues, each carrying the requirement ID in the branch name and the PR title.
Accepted — the acceptance test runs green with the requester watching. Not when the PR merges.
Live — object tagged, owner group set, runbook entry exists.
One requirement usually lands on several objects, and one dashboard usually rests on several requirements: REQ-118 arrives as segment and country dimensions on gold.mv_sales, while the monthly pre-aggregate under the same dashboard is its own requirement with its own owner. That is normal, and it is why the link is carried by the object rather than by the report.
Governed tags carry the warehouse end. They are GA, defined once at account level, and deployed in DDL rather than clicked into a UI:
sqlThe warehouse end of the link — deployed, reviewed, versioned
ALTER TABLE gold.agg_revenue_month
SET TAGS ('requirement' = 'REQ-121', 'owner' = 'grp_dwh_gold');
COMMENT ON TABLE gold.agg_revenue_month IS
'One row per month x region_sk x product group. Revenue excludes
status = CANCELLED (rule 1). Requirement REQ-121. Owner grp_dwh_gold.
Loaded daily 07:30 CET from gold.fct_order_line, after the 07:00 gold load.';
Which is worth doing because of what it makes queryable — the tables nobody can name a reason for:
sqlOrphan sweep — run monthly, in the team's own review
SELECT t.table_name
FROM dwh_prod.information_schema.tables t
LEFT JOIN dwh_prod.information_schema.table_tags g
ON g.schema_name = t.table_schema
AND g.table_name = t.table_name
AND g.tag_name = 'requirement'
WHERE t.table_schema = 'gold'
AND t.table_type = 'MANAGED'
AND g.tag_name IS NULL
ORDER BY t.table_name;
It returns two kinds of row: tables built before the process existed, and tables built around it last week. Both deserve a conversation. The second deserves it immediately, and it is much easier to have when the query found it rather than when you did.
Why here
Month fourteen, somebody asks why gold.agg_revenue_month excludes cancelled orders. Without the link the answer is archaeology: git blame, then a chat search, then a person who has left. With it, the tag names REQ-121, and REQ-121 names the rule, the owner, the acceptance number and the date it was agreed.
The reverse direction matters as often. When the owner asks to change the definition of revenue, you need every object that implements rule 1 before you can quote a cost — the tag sweep lists the candidates in seconds, and lineage then tells you what reads them.
Doing it
Put the requirement ID in the branch name, the PR title and the table tag. One string, three places, all greppable.
Set tags and comments in deployed DDL. A tag clicked into Catalog Explorer survives only until the pipeline next recreates the table.
Close issues on merge and requirements on acceptance — never the other way round, and never both at once.
Run the orphan sweep monthly and put the output into the team's review, not into your status report.
Embedding it
Let the team run the orphan sweep in front of the whole group the first time. Their own untagged tables make the argument better than you can.
Have them send the acceptance invitation and run the demo. If you drive the sign-off meeting, the requester's relationship is with you and it ends when you do.
Put the tag on the review checklist so it is caught while the DDL is still open and the change is free.
At handover, pick a gold table at random and ask a team member to trace it to its requirement. Two minutes means the link is real; ten minutes of searching means it is decoration.
Defaults
Requirement and issue are separate objects with separate owners and separate lifetimes.
Accepted means the acceptance test ran green with the requester in the room.
The link lives in the warehouse as a governed tag, not only in the tracker.
Rejected and cancelled requirements are kept — they are the record of what was already asked and answered.
The orphan sweep is a standing monthly item owned by the team.
Gotchas
Closing the requirement when the PR merges. 'Done' then means 'deployed', and the first person to notice the number is wrong is the person who asked for it — in a meeting, with an audience.
The requirement living in a chat thread. In eighteen months the reason revenue excludes cancelled orders sits in a channel of a tool the client has since replaced, and the rule gets re-decided differently.
One epic per report with forty issues under it. When a rule turns out to be wrong you cannot tell which change implemented it, so the investigation is a re-read of everything and the estimate for a one-line fix is a week.
Tags applied by hand in Catalog Explorer, or a tagged table renamed without touching the requirement. Both fail the same way: nothing errors, the link simply stops existing, and the orphan sweep is the only thing that notices.
Deploying DDL that sets a governed tag key nobody has created yet. Governed tags are defined once at account level and assigned by whoever holds that permission — not by the engineer writing the ALTER TABLE — so the release fails on the tag rather than on the table, and unblocking it needs a person who is not in the sprint. Create the keys with the catalogs, before the first table needs one.
The generic platform material lives in the official docs and is not restated here. These are the pages worth having open while you work through this route.