Bituser · Platform taxonomy

Platform taxonomy

The canonical vocabulary of the Bituser platform. Every capability is named once — as a Solution, Product, Feature, or Usage — and that name reads the same on the website, the rate card, the usage statement, and the Order Form.

Chain  Solution → Product → Feature → Usage Authority  Canonical
Solution Product Feature Usage
01

The four terms

Containment runs Solution ⊃ Product ⊃ Feature ⊃ Usage. A Solution is the one conceptual term — what a customer buys; the other three are system identifiers that name a Product, a Feature, and a Usage. Classification rides inside each term as a tag — Type on a Solution, IaaS / DaaS on the rest — never as a level.

Solution

Customer outcome

Solution Website Visit Email

A named group of ProductIDs delivering one customer outcome. It carries a Type that classifies its shape and sets the leading glyph and tag.

typeclassifier of the Solution's shape
containsone or more ProductIDs
deliversone customer outcome
namedsource → destination
Type
Pipeline A directed source → destination flow — ingress → egress, ingesting → activating. Named source → destination.
Resolution A request → response transform. One input, one verified output — no ingress leg, no stored state. Named input → output.
Product

Buyer-selectable unit

Product User from Page ProductID 8010

The identifier for a Product — the buyer-selectable unit within a Solution. A Product contains one or more Features and emits metered Usage.

identifiesa Product
classIaaS / DaaS
containsone or more Features
emitsmetered Usage
Feature

Reusable action

Feature Action Page Visit FeatureID 20081

The identifier for a Feature — a reusable action a Product performs. One or more Features make up a Product, and a Feature is shared across Products wherever the same action recurs.

identifiesa Feature
isa reusable action
belongs toone or more Products
example20081 · Action Page Visit
Usage

Metered event

UsageIaaSSUUsageID 921 UsageDaaSMAUsageID 602

The identifier for a Usage — the metered event and billing unit. Each Usage carries a Status (see §02) that, on a statement, sets its color.

identifiesa Usage
classIaaS / DaaS
carriesa Status
billson OK · SU or MA
Class
IaaS Infrastructure: real-time ingesting, graphing, and activation.
DaaS Data: identity and data resolution, billed per match.
02

Status

Status is a dimension on the Usage, held separately from the identifier so the event name stays stable and the outcome reads on its own. Every metered event resolves to one of four codes. OK = {SU, MA} is the billable grouping: only OK bills; NO and EX never do. A Solution carries a Type; a Usage carries a Status — the two never share a name.

SU Success — the event completed MA Match — a resolution landed NO No Match — resolved, nothing to bill EX Exception — the error status, never bills
Status vs Class Status and Class are independent. A Usage carries a Status because of what happened to it, not because of which pillar produced it. OK = {SU, MA} bills; NO and EX never do.
03

Nested in context

One token, nested in context. Every tier is the same tag — icon plus name — told apart by color, not typeface. The Solution is the sellable outcome, carried on a rounded blue pill; its Products, Features, and Usages are rectangular metered building blocks nested inside it. Each Feature collapses to its billable line; expand it to see every Status. This is the reusable card that renders each Solution at /solutions/.

Solution Pipeline Website Visit Email
Product User from Page ProductID 8010
Product User to Email ProductID 8110

UAIID = User Agent Instance ID.
Each Feature collapses to its billable line — expand it to see every Status (SU · MA · NO · EX). Service and Status are independent dimensions.

Generalizes This same Solution / Product / Feature / Usage pattern repeats for every Solution on the platform — each Usage billing on OK, whatever its Class. See them at /solutions/.
04

Billing logic

Billing follows Status, not the identifier. A Usage bills only when its Status is OK — SU or MA. NO and EX never bill.

Included & metered Value is charged on egress. Ingesting, Graphing, and Decisioning are included; Activating (IaaS) and Data (DaaS) are metered. Services are defined on /company/#platform.
Rates live on /pricing

This page defines how Usage bills. Rates, the billing floor, estimates, and the calculator live on /pricing — because the match rate is not one-to-one, unit prices can't be summed into a total here without misrepresenting cost.

05

Principles

P1

One token, four colors

Every tier is the same tag — an icon and a name — told apart by color, not typeface: Solution blue, Product purple, Feature amber, Usage green. The identical tag renders in the legend, the definitions, and the card.

P2

Shape encodes role

A rounded pill is a sellable outcome — the Solution. Rectangular blocks are metered building blocks — Product, Feature, Usage. Shape tells apart what a customer buys from what the platform meters.

P3

Classifiers don't nest

Type classifies a Solution; IaaS / DaaS classify Products and Usages; Status classifies a Usage. They ride inside a term as a tag — never as a level. Containment is Solution ⊃ Product ⊃ Feature ⊃ Usage.

P4

Reuse lives below the Product

A Feature is shared across Products wherever the same action recurs — the platform's cluster-for-reuse.

P5

Status is its own dimension

Status is independent of the pillar: SU and MA are green (both OK, both billable), NO is amber, EX is red. An IaaS Usage may carry MA and a DaaS Usage may carry SU; only the Status decides billing.

P6

One name, every surface

Each Solution, Product, Feature, and Usage is named once. The website, rate card, statement, and Order Form all reference that name — and every reserved word owns an icon, reusable as a facet.

06

Do & don't

Do

  • Name a Solution as source → destination
  • Carry Type on a Solution, Status on a Usage — never swap them
  • Bill a Usage on OK only — SU or MA, whatever its Class
  • Reference these canonical IDs; don't redefine them per surface
  • Don't

  • Derive a Usage's Status from its Class — Status is set by what happened, not by the pillar
  • Treat Type or Status as a level — they classify, they don't nest
  • Sum unit prices into a total — the match rate isn't one-to-one; use the /pricing calculator
  • Redefine a Product, Feature, or Usage name on any single surface
  • 07

    Where the term lives

    One term, four surfaces. The pill that labels a Product on the website is the same defined term that appears on the rate card, lines on the usage statement, and is referenced in the Order Form.

    Website

    Labels each capability by Solution and its Type.

    Rate card

    Lists each identifier by Type, Service, and Status.

    Statement

    UsageIDs render as lines, billed on OK status only.

    Order Form

    The canonical IDs are the defined contract terms.