Why every company starts with a source-of-truth document

Every company eventually argues with itself. A designer proposes a feature that contradicts the pricing model. A marketer writes copy that describes the product as something it is not. An engineer adds a data field that the privacy plan never allowed. Nobody is wrong on purpose. They are working from different memories of what the company was meant to be.

At Oryvelon, every company starts with a source-of-truth document — step five of our new-company protocol. It is short, it is written before code or design, and every later document is expected to agree with it. It is one of the simplest practices we have and one of the most valuable.

What "source of truth" means

In software, a source of truth is the one place where a piece of data is authoritative. Other systems may copy it, but when they disagree, the source of truth wins.

A source-of-truth document applies the same idea to a company's intent. Product specs, marketing briefs, technical plans, sales decks and website copy may all describe the company. When they disagree with each other, the source of truth decides. When they disagree with the source of truth, either they are wrong or the source of truth needs a deliberate update.

The group itself works this way. Oryvelon has a master project document that defines the group's role, its companies and domains, the boundaries between them, and the technical and operating standards they share. Company-level documents must not contradict it.

What goes into it

A company's source of truth is usually a few pages. It covers the same headings every time, which makes companies easy to compare and documents easy to navigate.

1. Identity. The company's name, domain and one-sentence description.
2. Customer and problem. Who the company serves and what problem it solves, in the customer's language.
3. Category. Software, marketplace, AI product, commerce, services, education — and what that implies.
4. Revenue mechanism. Who pays, for what, and how revenue repeats. See Designing a recurring revenue loop.
5. What the company will not do. Often the most useful section.
6. Data classification and rules. What data it holds, how sensitive it is, and the resulting rules for isolation, access, retention and AI use.
7. AI principles. Which facts must come from verified systems, and what AI is allowed to do. See AI explains, verified data decides.
8. Relationship to the group. What the company shares with Oryvelon, what it does not, and how the relationship is shown publicly.
9. Brand voice and positioning. How the company speaks and what claims it must never make.
10. Success measures. The KPIs and checkpoint dates. See Continue, stop or scale.

The "will not do" section

If we had to keep only one section, it might be this one. Positive descriptions are easy to stretch; explicit boundaries are not.

Some examples of the kind of statements that belong here:

• Oryvelon will not sell agency services directly; those belong to WeAreMedia.
• ZodiVela will not present readings as predictions or as medical, legal or financial advice.
• KeşifAtlası will not let an AI model decide eligibility; the verified rules database does.
• EduRelia will not use student data in any consumer product or for marketing.
• MerchNivo will not use one store's data for another store or another product.
• CastLyra will not share talent contact details outside its access rules.

Each of these lines settles a whole category of future debates in advance. When someone proposes a clever idea that crosses one, the conversation is short.

Why it saves time

A source-of-truth document can look like overhead. In practice it pays for itself quickly.

It resolves disagreements fast. When two people disagree about direction, the first question is "what does the source of truth say?" Often that settles it. If it does not, the disagreement becomes a clear proposal to change the document, which is a better conversation than an argument about opinions.

It onboards people faster. A new team member, freelancer or partner can read a few pages and understand what the company is, what it is not and why. That is far quicker than piecing it together from meetings and chat history.

It keeps AI tools aligned. When we use AI assistants to help draft content, specs or code, the source of truth is part of the context they are given. That keeps generated work consistent with the company's intent — and makes it obvious when something does not fit.

It prevents slow drift. Companies rarely change direction in one dramatic decision. They drift, one reasonable-sounding exception at a time. A written reference makes drift visible.

It makes the company separable. Anyone evaluating a company — a partner, investor or acquirer — wants to know what it is and what it has committed to. The source of truth answers that directly. See Designing every company so it could stand alone.

Keeping it alive

A document that is written once and never touched becomes a museum piece. We keep sources of truth alive with a few habits.

Short beats complete. A few pages that everyone reads are worth more than fifty that nobody does. Details belong in specs; the source of truth holds decisions.

Versioned, with a change log. Every change records what changed, when, and why. Months later, the history tells the story of how the company evolved.

Updated deliberately. Changing the source of truth is a decision, usually made at a checkpoint or allocation review. It is never edited casually to make a proposal fit.

Referenced constantly. Specs, briefs and plans link to the relevant section. If a document cannot point to the part of the source of truth it serves, that is a warning sign.

Reviewed at checkpoints. At each continue, stop or scale checkpoint we ask whether the source of truth still describes the company accurately. If the company has learned something fundamental, the document changes.

A hierarchy of documents

Sources of truth sit at the top of a simple hierarchy:

1. The group master document — Oryvelon's role, companies, boundaries and standards.
2. Each company's source of truth — identity, customer, revenue, boundaries, data rules.
3. Specifications and plans — product specs, technical designs, marketing plans.
4. Working documents — tickets, drafts, meeting notes.

Each level must agree with the levels above it. When a lower-level document needs something the higher level forbids, the higher level is either updated deliberately or the lower-level document changes.

Common objections

"We're too small for this." Small teams benefit most, because they have the least time to repeat the same arguments.

"It will be out of date immediately." Only if nobody updates it. Keeping it short and reviewing it at checkpoints solves most of this.

"It kills creativity." It channels it. Knowing what a company will not do makes it easier to be bold within the space it will.

How to write one

If you want to try this for your own company, start with a blank page and the ten headings above. Give yourself an hour. Write a paragraph or less under each. Where you cannot, you have found an unresolved question that deserves attention. Share the draft with the people who work on the company, invite disagreement, and settle it in writing.

Then use it. Link to it from every spec. Open it at the start of every planning session. Change it when you learn something fundamental, and write down why.

What the group-level source of truth looks like

Oryvelon's own master document is a good illustration of the format, because it covers everything the companies inherit. Its sections, in order, are roughly:

1. The core decision and unchangeable rules. Oryvelon is a company builder and venture group — not an agency, not a single SaaS product, not a portfolio showcase.
2. Oryvelon's mission and what it will not do. Build, own and operate companies; never run each company's daily customer operations centrally or merge products into one application.
3. The exact company and domain list. Every brand, its category, its main job and its revenue model.
4. Brand boundaries between companies. How each company relates to the others, including which authority sites may send qualified traffic where.
5. Website information architecture. The pages oryvelon.com has, and what each is for.
6. The design direction. Minimal, editorial, technology, premium, global — and what to avoid.
7. The "An Oryvelon company" standard. Where the group relationship may appear, and where it must not.
8. The shared technical core. Which services provide DNS, code hosting, deployment, databases, AI access, background jobs, email, analytics and monitoring.
9. The AI gateway. Routing, prompt registry, budgets, safety, observability, fallbacks and caching — with the critical rule that AI is not the source of business truth.
10. Data isolation and privacy boundaries. The table of what each company keeps separate.
11. Domain, DNS and email standards.
12. Repository and code organisation.
13. Environments. Local, preview, staging and production, and which data each may contain.
14. AI governance. Separate projects, budgets, server-side keys, versioned prompts, structured outputs, evaluation, fallbacks, human escalation.
15. Shared and non-shared libraries.
16. Analytics and UTM standards.
17. Search, entity and AI visibility.
18. Security, access and roles.
19. Finance and cost control.
20. The new-company protocol.
21. Content policy for insights.
22. Implementation order and QA criteria.

That may sound long, but each section is only a few lines. It fits in a document you can read in one sitting — and every company-level source of truth starts by inheriting it.

Source of truth, strategy deck, wiki: what is the difference?

Companies accumulate many kinds of documents. It helps to be clear about what the source of truth is not.

A strategy deck persuades. It is written for an audience — investors, partners, a board — and it emphasises the most compelling parts of the story. A source of truth describes; it includes the boundaries and the uncomfortable constraints.

A wiki stores. It grows in every direction, contains contradictions and is rarely read from start to finish. A source of truth is short, curated and internally consistent.

A product spec details. It explains how a specific feature will work. A source of truth explains why the product exists and which rules every feature must respect.

A brand guide styles. It governs how the company looks and sounds. A source of truth sets the positioning and claims the brand guide must support.

All of these documents are useful. The source of truth is the one they should all agree with.

Signs a source of truth is failing

We watch for a few symptoms that suggest a company's source of truth has stopped doing its job:

• people answer "what is this company?" differently from the document;
• specs and briefs rarely link to it;
• the last change was long ago, even though the company has clearly learned important things since;
• a decision was made that contradicts it, and nobody noticed;
• new team members are told "don't bother reading that, it's out of date".

When we see these signs, the fix is usually quick: a short session to reconcile the document with reality, record the decisions that were made informally, and remove anything that no longer applies.

Using the source of truth with AI assistants

We use AI assistants to help draft specs, content, code and plans. The source of truth has become one of the most important inputs we give them.

When an assistant receives a company's source of truth as context, its drafts start from the right assumptions: the right customer, the right tone, the right boundaries. It is far less likely to propose a feature that crosses a data rule or a claim the brand must never make. And when it does, the conflict is easy to spot, because the rule is written down and can be pointed to.

The same applies to automated work. Scheduled jobs that update content or check a site's health are given the relevant source of truth and content rules as part of their instructions. That keeps automation aligned with human intent, even when nobody is watching in real time.

A worked example: KeşifAtlası

The ten headings are easier to understand with one company filled in. Here is an illustrative, shortened view of how the source of truth for KeşifAtlası reads under a few of them. The wording is simplified for this article, but the shape is real.

Identity. KeşifAtlası helps people understand visa and relocation options, starting from Türkiye. It explains which routes may fit their situation, based on a verified rules database.

Customer and problem. People who are considering a move or a long stay abroad and cannot tell which rules apply to them. Official information is scattered, written for lawyers and changes without notice.

Revenue mechanism. A free eligibility test, followed by a paid, more detailed report for people who want it. The logic of that step is described in From free test to paid report.

Will not do. Let a model decide eligibility. Promise an outcome that depends on an authority. Answer a question the rules database does not cover as if it did.

Data rules. Collect only what the eligibility rules need. Keep answers separate from marketing lists. Delete test data on a defined schedule. See Data retention and deletion.

AI principles. The rules engine produces the result; AI explains it in plain language and must reference the rule it is explaining. Hard or unusual cases go to a person, as described in Human escalation in AI products.

Notice how much this settles. A proposal to "let the model estimate eligibility when a rule is missing" is answered before anyone builds it. A request to reuse test answers for a newsletter segment is answered too. Nobody needs a meeting.

How a change actually happens

Changing the source of truth should be possible, but never quiet. Our process is short.

1. Someone writes a proposal. One paragraph: what should change, which section, and the evidence behind it. Evidence usually comes from a checkpoint, customer conversations or a problem that keeps recurring.
2. The owner of the company and a founder review it. Most proposals are decided within days. Some are sent back for more evidence.
3. The change is made with a log entry. Date, section, old wording, new wording, reason.
4. Dependent documents are checked. If the revenue section changed, the pricing page, onboarding copy and analytics events are reviewed for anything that now disagrees.

Step four is the one teams skip. A source of truth that changes while the specs below it stay the same creates exactly the confusion it was meant to prevent.

A typical, hypothetical log entry looks like this:

Common mistakes when writing one

We have made most of these ourselves at some point.

Writing aspirations instead of decisions. "We want to be the most trusted platform in our category" tells nobody what to do. "We will not show a result without the rule that produced it" does.

Leaving the data section vague. "We take privacy seriously" is not a rule. Name the data, its sensitivity, who can access it, how long it is kept and whether AI may see it.

Copying the group document. A company's source of truth inherits the group's rules; it does not need to repeat them. It should record what is specific to this company.

Letting it grow into a spec. When a section starts describing screens and buttons, the detail belongs in a product document that links back.

Having no owner. Every source of truth has one named person responsible for keeping it accurate. Without that, everyone assumes someone else will update it.

A quick checklist

Before a new company moves into build, its source of truth should pass a short test:

• Can a newcomer describe the company in one sentence after reading it?
• Is it clear who pays, and for what?
• Does the "will not do" section contain at least a few specific, testable statements?
• Is every category of data named, with a rule for access, retention and AI use?
• Does it say which facts come from verified systems?
• Are the checkpoint KPIs and dates written down?
• Is there an owner and a change log?

If any answer is no, the gap is cheaper to close now than after the first release.

Summary

A source-of-truth document is a small investment with a large return: faster decisions, faster onboarding, less drift, better alignment with AI tools and a company that is easier to understand from the outside. Every Oryvelon company has one, and the group has one too. It is the first thing we write, and the thing we return to most often.

Questions and answers

What is a source-of-truth document?

A short written reference that defines what a company is, who it serves, how it earns, what it will not do and which rules apply. Later documents must agree with it.

Does Oryvelon itself have a source of truth?

Yes. The group's master project document defines Oryvelon's role, companies, domains, data boundaries and operating standards.

How often is the source of truth updated?

Whenever a deliberate decision changes something fundamental. Updates are versioned so the history of decisions is visible.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Company Building

NextBrand architecture for a multi-company group: parent brand vs. product brands →