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, and the usage statement.

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 Disposition (see §02) that, on a statement, sets its color.

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

Disposition

Disposition 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 Disposition — 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 disposition, never bills
Disposition vs Class Disposition and Class are independent. A Usage carries a Disposition 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 Disposition. This is the reusable card that renders each Solution at /solutions/.

SolutionPipelineWebsite Visit → Email
ProductUser from PageProductID 8010
ProductUser to EmailProductID 8110

UAIID = User Agent Instance ID.
Each Feature collapses to its billable line — expand it to see every Disposition (SU · MA · NO · EX). Service and Disposition 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 Disposition, not the identifier. A Usage bills only on a Success (SU) or Match (MA) disposition. NO and EX never bill.

Included & metered Value is charged on egress and on data. Ingesting, Graphing and Orchestrating are included; Activating (IaaS) and Sourcing (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; Disposition 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

Disposition is its own dimension

Disposition 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 Disposition decides billing.

P6

One name, every surface

Each Solution, Product, Feature, and Usage is named once. The website, rate card, and statement 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, Disposition 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 Disposition from its Class — Disposition is set by what happened, not by the pillar
  • Treat Type or Disposition 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, three surfaces. The pill that labels a Product on the website is the same defined term that appears on the rate card and lines on the usage statement.

    Website

    Labels each capability by Solution and its Type.

    Rate card

    Lists each identifier by Type, Service, and Disposition.

    Statement

    UsageIDs render as lines, billed only on a Success or a Match.