What does the nightly sales load actually do?
- 01Nightly sales loadchecks, then item lines, then tender
- 02Trading day · 04:00item lines inherit the header’s business date
2 engrams · PL/SQL, runbook, one closed ticket
Living knowledge space · Oracle data warehouses
Everything your warehouse knows, in one place you can ask.
Your PL/SQL knows part of it. Confluence knew part of it, nineteen months ago. Jira, Slack, the franchise agreement and about a dozen people hold the rest. There is no single place to ask your warehouse a question.
Telvi is that place — a living, queryable knowledge space over your Oracle EDW. Feed it everything, then ask it anything it has been fed: what a package does, how a load gets extended, why the trading day closes at 04:00, who owns the delivery feed. Every answer cited.
Cerebrum · Oracle EDW · food service & retail
- PL/SQL & ODI
- Confluence & contracts
- Jira
- Slack
- People
- Engram
Asked what What does the nightly sales load actually do?
Four ordinary questions, four different shapes of answer, one knowledge space. Every node is a unit of knowledge with its evidence attached — so answers arrive as citations, not as ten tabs.
Three words. One idea.
- Engram
- One unit of knowledge. A statement, its reasoning, its evidence, its owner, its expiry.
- Cerebrum
- The space itself. Every engram, connected, and continuously re-checked against source.
- Telvi
- The platform that builds it, keeps it alive, and answers from it — for people and agents.
The gap
There is no single place to ask
Nothing below is unknowable. It is all known, by someone or something — just not in one place, and not in a form anyone can query. These are five ordinary questions from one ordinary week.
-
what
What does
PKG_SALES_DAILY_LOADactually do?4,200 lines of PL/SQL, plus one person’s memory of the 2019 rewrite
half a day of reading
-
how
How do I add a late-night daypart without breaking comp sales?
A 2019 ticket, two Slack threads, and practice nobody ever wrote down
ask three people, hope
-
why
Why does the trading day close at 04:00 and not midnight?
A franchise agreement nobody in engineering has read
nobody knows
-
who
Who owns the delivery revenue feed now?
git blame, pointing confidently at someone who left in Marchtwo days of forwarding
-
when
When did the comp-base rule last change, and on whose call?
MV definition, a closed Jira, an earnings-week Slack thread
unanswered
Five questions. Five different systems. Not one of them is a place you can ask. That isn’t a documentation problem you can write your way out of — it’s a missing layer.
The unit
What the space is made of
In neuroscience, an engram is the physical trace a memory leaves behind. In Telvi, an engram is one unit of knowledge: a statement, whatever reasoning was recoverable, the evidence that proves it, the team accountable, and the day it was last checked. Here is one from a delivery revenue feed.
Engram
eng_9d40 · revenue.delivery.gross_basis
verified 3d ago
States
Third-party delivery orders land at gross menu price. Commission is booked separately.
Reasoning recovered
Aggregator settlement files arrive net of a 22–30% commission, but both franchise royalty and comparable-store sales are calculated on gross menu price. Loading the settlement value understated comp sales by 3.1% across the pilot markets — which is why the ODI mapping re-grosses every line before it reaches the fact table.
Evidence
- ODI
MAP_DELIVERY_ORDERS_STGwhat it does - Jira
EDW-3106c11the 3.1% finding - Slack #revenue-recognitionhow it was decided
- Aggregator MSA §4 rate cardwhy it must be gross
- Confluence “Delivery feed spec v1”says net — flagged
- Ravi M., Revenue Accountingwho owns it
One engram, six sources
Filter it down and watch the knowledge thin out. The mapping shows what happens; only the MSA explains the rate, only Jira holds the number, only Slack holds the decision, only a human knows who owns it now. Feed the space more, and it knows more.
- Cited — every statement resolves to an artefact you can open.
- Owned — a named team is accountable, not a wiki page.
- Perishable — it expires and re-verifies instead of quietly going wrong.
- Addressable — it has an ID, so an agent can fetch it directly.
Queryable
Ask it anything it has been fed
The space isn’t organised by question type — it’s organised by what your warehouse contains. So the shape of the answer follows the shape of the question, and each one resolves through different engrams.
How do I add a late-night daypart without breaking comp sales?
- 01Daypart boundarieseffective-dated, never updated in place
- 02Comp base · 13 periodsreporting-critical, tied to disclosure
- 0353rd week → period 13join on fiscal week, never on date
3 engrams · the procedure nobody wrote down
Why does the trading day close at 04:00?
- 01Trading day · 04:00the PL/SQL constant
- 02Royalty on gross salesfranchisees settle on the POS close
- 03Franchise agmt cl. 6.304:00 to 04:00, contractually
3 engrams · ends at a clause no engineer had read
Who owns the delivery revenue feed now?
- 01Delivery feed ownershipmoved when the author left in March
- 02Delivery at grossRevenue Accounting on the numbers, EDW on the pipe
2 engrams · git blame would have sent you to the wrong person
And when it hasn’t been fed something?
It says so. An unfed area returns “no engram covers this”, names the nearest owner, and lists the source you’d have to connect to close the gap. A knowledge space that bluffs is worse than an empty one.
Coverage is a number you can see, not a promise
Method
How the space gets built
Four stages, running continuously — because knowledge that never re-checks itself is just an old Confluence page.
-
01
Feed it
PL/SQL packages, ODI mappings, materialised views and scheduler chains, alongside Confluence, Jira, Slack, email, contracts and ownership signals. Deliberately not code-only.
-
02
Resolve what things are
BUSINESS_DTin the schema, “trading day” in Finance and “that 4am thing” in Slack are one entity. Nothing joins until this is right. -
03
Form engrams
Statement, reasoning, evidence, owner, confidence. Conflicts aren’t averaged away — the stale Confluence spec gets flagged against the source that disagrees with it.
-
04
Keep it true
When the mapping, the ticket or the agreement changes, the engrams citing it re-verify. Knowledge that can go stale silently is worse than none.
Why “living” isn’t decoration
- It re-reads on change An edit to a mapping re-opens every engram that cites it.
- Confidence decays Unverified knowledge is served with its age, or not served at all.
- Contradictions surface Production disagreeing with Confluence becomes a flag, not a surprise.
- It gets denser Every question asked and every correction made feeds back in.
Who’s asking
People ask it. So do your agents.
An agent with schema access and nothing else reads a predicate, infers an intent that was never true, and ships it with total confidence. It isn’t a model problem — it’s that nothing in your stack could tell it what the warehouse knows. Engrams are addressable, so it can just ask.
Task: “Comp sales look low — fix the store filter in MV_COMP_SALES_PERIOD.”
Reads the 13-period predicate, finds the Confluence page saying 12 calendar months, “corrects” the MV to match the documentation and refreshes it. Silently re-states comparable sales nine days before an earnings call, with a green build.
Confidently wrongTask: “Comp sales look low — fix the store filter in MV_COMP_SALES_PERIOD.”
Fetches the comp-base engram, finds the disclosure wording behind the 13-period rule, sees the Confluence page already flagged as the stale source, declines the change and opens a documentation-fix ticket instead — citing Jira, Slack and the disclosure.
Correct, and it shows its workSame space, two kinds of reader: a new EDW engineer reading engrams on Monday, an agent fetching them over MCP or the API on Tuesday. Neither has to interrupt anyone.
Cost of scattered knowledge
The bill you already pay
None of this shows up on a dashboard. It shows up as slow periods, risky month-end changes, and the same four people being interrupted about a warehouse nobody fully remembers building.
When the person who built it leaves
60–70%
of what they knew about the warehouse is not written down anywhere. It doesn’t transfer at handover — it walks out on the last day, and the space you could have fed never got fed.
- Twenty years of trading-calendar decisions, unrecorded
- Gaps surface months later, at period close
- Replacement cost is paid in delivery speed and restatements
2.1K+PL/SQL objects
740+ODI mappings
260+Materialised views
1.2K+Scheduler jobs
6.5K+Sites reporting daily
90+Analysts & engineers
This is the surface one new EDW engineer — or one agent — is expected to hold in their head, with no single place to look it up.
Boundaries
Not a wiki. Not a search box.
A wiki
A place to write knowledge down, once, by whoever had time that quarter.
Static and unowned. It can’t tell you whether production still agrees.
Enterprise search & chatbots
Finds the documents. Ranks them well. Hands you ten tabs.
Retrieval, not knowledge. You still assemble the answer yourself.
Telvi
A knowledge space: assembled once, cited, owned, re-verified, and queryable.
Ask it anything it has been fed — and it tells you when it hasn’t.
Six months in
What changes when the space exists
Nobody is the documentation
Anita’s leave stops being a period-close risk.
Onboarding asks the space
Week one gets answers, not a queue outside three desks.
Stale specs get caught
Contradictions surface as flags, not as restatements.
Agents stop guessing
Grounded in your warehouse, with citations you can audit.
Demo
Bring us a question nobody can answer
Thirty minutes, one real slice of your Oracle warehouse — a schema plus your Confluence and Jira. We’ll build the space live and you can check every citation.
Book a demoor email hello@telvi.ai
Contact
Let’s talk knowledge
- Phone
- +91 824 961 9206
- hello@telvi.ai
- Security
- security@telvi.ai
- Web
- telvi.ai
- Address
- 2nd Floor, Plot 343, Infocity Ave, Sishu Vihar, Patia, Bhubaneswar, Odisha 751024, India