Skip to content
Brihat InfotechBrihat Infotech

Glossary

The words that cause the most confusion, defined.

Not a dictionary — these are the terms that actually derail first meetings, each with the part a dictionary leaves out: why it matters commercially.

Terms defined
22Terms defined
Every one has its own anchor
LinkableEvery one has its own anchor
No term defined using itself
PlainNo term defined using itself

AI guardrails

The controls around a model that decide what it may do unsupervised: input and output filtering, policy checks before a consequential action, confidence thresholds that route a case to a human, and a complete log of every decision.

Why it matters. In a regulated setting the guardrails are the product. A model that is right most of the time and unaccountable the rest cannot be put in front of a regulator.

See alsoEvaluation setRetrieval-augmented generation

Build versus buy

The decision between commissioning custom software and licensing an existing product. The deciding question is whether the process in question is a source of competitive advantage: if a competitor could buy the same product tomorrow and lose nothing, buying is correct.

Why it matters. Most organisations should buy more than they do and build fewer, larger things. Heavy customisation of a bought product is the worst of both — build cost without ownership, and every vendor upgrade becomes a re-testing exercise.

See alsoTotal cost of ownershipSystem of record

Build-Operate-Transfer

also BOT

A model where a vendor recruits and runs an offshore team, then transfers it to the client's own entity on an agreed date. In genuine BOT the transfer date, price and mechanism are fixed in the first contract; where they are left to be negotiated later, it is outsourcing with a friendlier name.

Why it matters. The distinction decides whether you end up owning a capability or renting one indefinitely. Ask to see the transfer clause before signing, not at the point you want to use it.

See alsoOffshore Development CentreStaff augmentation

Canonical data model

A single agreed definition of a shared business entity — customer, order, patient — that every connected system maps to, rather than each pair of systems agreeing a private translation between them.

Why it matters. Without one, integrating n systems takes roughly n² mappings and every new system multiplies the problem. It is also usually where the real disagreement surfaces: two departments defining 'active customer' differently.

See alsoSystem of recordData residency

Data residency

The requirement that data is stored, and sometimes processed, within a specific country's borders. In India, the RBI requires payment system data to be stored domestically, and sectoral regulators impose further conditions.

Why it matters. It decides your cloud region before anything else about the architecture does, and retrofitting it is a migration rather than a setting.

See alsoDPDP Act 2023

Discovery phase

also inception, requirement engineering

A paid, contracted phase before any build, producing process maps of how an organisation actually works, a target architecture and a costed phased plan. It ends with a decision to proceed or not, and its artefacts belong to the client either way.

Why it matters. It is the only point at which a fixed price for the build means anything. A quote given before discovery is either padded for the worst case or optimistic, and you pay for whichever it was.

See alsoSolution blueprintTotal cost of ownership

DPDP Act 2023

also Digital Personal Data Protection Act

India's data protection law, governing how organisations collect and process personal data. It requires consent that is free, specific, informed and unambiguous, limits processing to the stated purpose, and obliges organisations to appoint a grievance officer.

Why it matters. Consent, retention and erasure are cheap to design into a data model and expensive to retrofit. Children's data and health data carry stricter conditions.

See alsoData residency

Enterprise resource planning

also ERP

One system holding the operational core of a business — orders, procurement, production, inventory, and the finance that follows them — so those functions read and write the same records rather than reconciling separate ones. The scope is what distinguishes it from accounting software, which owns the ledger alone.

Why it matters. The word covers everything from a packaged product for twenty users to a decade-long platform programme. Establishing which one is meant, and which modules are actually in scope, prevents most of the misunderstanding in a first meeting.

See alsoSystem of recordMaster dataBuild versus buy

Evaluation set

also eval, golden set

A fixed collection of inputs with known-good outputs, scored automatically, used to tell whether a change to an AI system made it better or merely different. The equivalent of a test suite for behaviour that is not deterministic.

Why it matters. Without one, tuning an AI system is superstition — every change feels like an improvement to whoever made it. It is also the only way to detect a regression before a user does.

See alsoRetrieval-augmented generationAI guardrails

Hypercare

The period immediately after go-live when the build team stays engaged at full intensity, before an engagement moves to normal support. Typically two to six weeks.

Why it matters. It is when reality arrives: real data volumes, real user behaviour, the integrations nobody could test properly. A proposal with no hypercare has moved that risk onto the client.

See alsoService level objective

Legacy modernisation

Replacing or restructuring a working but unmaintainable system while it keeps running. Usually incremental — routing traffic away from the old system component by component — rather than a rewrite followed by a cutover.

Why it matters. The incremental route is slower and much less likely to fail. Big-bang rewrites fail on the parts nobody documented, which are discovered at cutover when there is no way back.

See alsoStrangler patternSystem of record

Master data

also reference data, master records

The records a business refers to repeatedly rather than transacts — items, customers, vendors, locations, accounts, units of measure. Transactions describe events; master data describes the things events happen to, and it is shared across every module that touches them.

Why it matters. It decides migration timelines. Transactional history is large but well-formed; master data is small and inconsistent, because it was typed by people over years across sites. Profiling it before a project is quoted is the cheapest schedule insurance available.

See alsoCanonical data modelEnterprise resource planningSystem of record

Multi-tenancy

also multitenant architecture

One running instance of an application serving many customers, with each customer's data isolated from the others. Isolation can be enforced at row, schema or database level; the choice determines operating cost, and how convincingly the arrangement can be explained to a customer's auditor.

Why it matters. It is the hardest architectural decision to reverse. Shared-schema is cheapest to run and hardest to defend to a regulated buyer who wants their data in a separate database in a stated region — and retrofitting isolation later is close to a rewrite.

See alsoData residencySystem of record

Offshore Development Centre

also ODC, GCC, captive centre

A dedicated engineering unit operated in another country for a single client, staffed and managed by a vendor but working only on that client's roadmap. Distinct from project outsourcing, where a vendor delivers a defined scope with a team you do not see.

Why it matters. An ODC is worth its overhead above roughly fifteen engineers. Below that, two dedicated pods usually cost less and carry the same accountability.

See alsoBuild-Operate-TransferStaff augmentation

Parallel run

also dual running, shadow run

Operating an old system and its replacement simultaneously on the same real inputs, then reconciling the outputs record by record. It is a verification method rather than a transition method: the point is to find where the two disagree while both are still available to be compared.

Why it matters. It is the only reliable way to recover behaviour that exists in code but in no document. Each discrepancy explained is a rule nobody had written down, and that log becomes the specification a rewrite never had.

See alsoStrangler patternLegacy modernisationMaster data

Retrieval-augmented generation

also RAG

A technique where a language model is given relevant passages retrieved from a document set at query time, and answers from those rather than from what it memorised during training. The retrieval step, not the model, is what determines answer quality.

Why it matters. It is how an AI system can cite a source and be corrected by updating a document rather than retraining. A disappointing result usually traces back to retrieval, which is an information-retrieval problem rather than an AI one.

See alsoEvaluation setAI guardrails

Service level objective

also SLO, error budget

An internal reliability target — for example 99.95% of requests served successfully over 30 days — with the shortfall treated as an error budget that may be spent on change. Distinct from an SLA, which is the contractual promise to a customer.

Why it matters. An SLO gives reliability work a stopping point. Without one, 'make it more reliable' has no definition of done and competes badly against features.

See alsoHypercare

Solution blueprint

The document produced by a discovery phase: target architecture, integration contracts, module scope, phase plan and the success metrics the engagement will be judged on. Written to be buildable by any competent firm rather than only by its author.

Why it matters. If a blueprint can only be executed by the firm that wrote it, it is a lock-in mechanism rather than a plan. That is a fair thing to test for before commissioning one.

See alsoDiscovery phase

Staff augmentation

also team augmentation, resource augmentation

Adding individual external engineers into a client's existing team, managed by the client's own process. The client directs the work; the vendor supplies and retains the people. It differs from a dedicated pod, where the vendor also supplies delivery management and accountability for output.

Why it matters. The failure mode is rotation. If the supplier can swap people without your agreement, the domain knowledge you are paying to build leaves with them.

See alsoOffshore Development CentreBuild-Operate-Transfer

Strangler pattern

An approach to replacing a legacy system in which new functionality is built alongside the old one and traffic is redirected piece by piece, until the original has no callers left and can be retired.

Why it matters. It gives you an exit at every step. Each component moved is independently verifiable, and a problem affects one route rather than the whole system.

See alsoLegacy modernisation

System of record

The authoritative source for a class of business data — the system whose version is correct when two disagree. ERP for finance and operations, HIS for patient records, core banking for accounts. Everything else reconciles to it.

Why it matters. Systems of record are the ones a business cannot switch off for a week, which is why they are engineered differently: audit trails, migration planning and uptime targets that a reporting tool does not need.

See alsoLegacy modernisationCanonical data model

Total cost of ownership

also TCO

The full lifetime cost of a system: build or licence, hosting, support, upgrades, integration maintenance and the internal effort to run it. For enterprise software the purchase price is usually a minority of it.

Why it matters. TCO is what decides build versus buy, and it is why the comparison has to run over the system's lifespan. Licence costs compound with headcount; build costs are front-loaded and then flatten.

See alsoBuild versus buyDiscovery phase

A term we have missed, or one you think we have defined badly? Tell us — this list grows from real conversations.

Next step

Bring us the problem. We will bring the architecture.

A discovery call takes forty-five minutes. You leave with our read on the problem, the shape of the system we would propose, and a straight answer on whether we are the right team for it.

  • No sales deck
  • An engineer on the call, not an account manager
  • NDA before you share anything