Bituser · Platform taxonomy

Token specification

One visual grammar for the platform taxonomy — built so a token reads the same on the website, the rate card, the usage statement, and the Order Form.

Canonical. This specification is the source of truth. Every surface — including the live website — conforms to it, not the reverse.
Chain  Solution → Product → Feature → Usage Authority  Canonical Brand  #5491E6 Updated  Jun 2, 2026
PipelineSolution IaaSProduct Feature DaaSUsage
01

Brand color

Anchored to the blue Bituser already publishes (#5491E6, the site theme color). Blue carries the infrastructure-and-trust register that fits user data infrastructure, so it owns the one conceptual tier — Solution. The three system-identifier tiers stay neutral. One ramp, used with intent.

400 signature accent — arrow, links, focus, brand mark 600 solid Solution fill 200 Type classifier on the Solution pill 800 text on light-blue fills
Why 600, not 400 The published #5491E6 is too light to carry white text at pill sizes (≈3.3:1, below the 4.5:1 bar). The solid Solution token drops one stop to #2E63B4 (≈5.8:1, passes AA), while the exact published hex lives on as the bright accent on light backgrounds — so the brand color is preserved, just placed where it stays legible.
02

The four tokens

Containment runs Solution ⊃ Product ⊃ Feature ⊃ Usage. The spine is the typeface flip — sans for the one conceptual tier, monospace for the three metered system identifiers. Classification (Type on Solution, IaaS / DaaS on the rest) rides inside the token as a tag, never as a level.

Solution

Customer outcome

PipelineWebsite Visitor Email

The sellable unit, named source → destination. Carries a Type classifier (Pipeline today; others later) that sets both the leading glyph and the tag.

typefaceManrope · sans, Sora · display
size / weight16px / 500
fill#2E63B4 (brand-600)
text#FFFFFF · arrow #A8C8F4
radius999px (full pill)
classifierType tag (brand-200) + white divider
Product

Billable building block

IaaSUser from Page

The atomic ProductID, classified IaaS or DaaS. Monospace begins here. A Product is composed of one or more Features and emits its own match Usage.

typefaceIBM Plex Mono · mono
size / weight13px / 500
fill#FFFFFF
text#1B1B17 (ink)
border1px solid rgba(27,27,23,.13)
radius6px (chip)
classifierIaaS / DaaS tag + divider rule
Feature · internal

Reusable action

page.match

The FeatureID — one action a Product performs. Documented and agreement-grade, but the quietest token: dashed, muted, hidden on customer surfaces initially. Shared across Products, which is the cluster-for-reuse — so no Blueprint tier is needed.

typefaceIBM Plex Mono · mono
size / weight12.5px / 400
filltransparent
text#6B6A62 (muted)
border1px dashed rgba(27,27,23,.24)
radius6px
visibilityinternal-first · billing & agreements
Usage

Billable event

IaaSUser from Page · match DaaSCookie to Hash Email

The metered UsageID — an IaaS product-match or a DaaS microtransaction. Smallest, recessed, telemetry register. The leading dot marks an event; in a statement it takes the outcome color.

typefaceIBM Plex Mono · mono
size / weight12px / 400
fill#F3F2EB (panel)
text#3A3A34
radius6px
classifierIaaS / DaaS tag + event dot
outcomesmatch no_match error
03

Nested in context

One Solution, two Products, their reusable Features, four UsageIDs. Each IaaS Product emits its own match event and the DaaS microtransaction it triggers — four billable lines.

PipelineWebsite Visitor Email
IaaSUser from Page
page.matchreusable action
IaaSUser from Page · matchproduct transaction
DaaSCookie to Hash Emaildata microtransaction
IaaSUser to Email
email.matchreusable action
IaaSUser to Email · matchproduct transaction
DaaSHash Email to Emaildata microtransaction
04

Usage rates & statement

Same format as the live pricing page — Type · Service · Product / Feature / Usage ID · Cost / Call — extended with counts and amounts for the client rollup. The tokens that label the platform become the line items.

Type Service Product / Feature / Usage ID Cost / Call Count Amount
IaaSIngestionUser from Page · match$0.002012,480$24.96
DaaSDataCookie to Hash Email$0.01009,360$93.60
IaaSActivationUser to Email · match$0.00158,910$13.37
DaaSDataHash Email to Email$0.01008,910$89.10
Website Visitor → Email$221.03

Platform minimum $2,000/mo · then usage-based · all prices in USD · figures illustrative

Prices subject to change

Rates for IaaS and DaaS services are variable and may be updated at any time. A statement reflects current rates as of its issue date.

Agreement reference

ProductIDs, FeatureIDs, and UsageIDs are the canonical identifiers referenced in the service agreement, and are subject to automated updates from the Bituser platform feed.

05

Principles

P1

Typeface encodes register

Sans = conceptual, customer-facing (Solution). Mono = a real metered identifier (Product, Feature, Usage). The flip is the strongest cue — preserve it above all else.

P2

Fill weight descends with altitude

Solid → outline chip → dashed ghost → recessed panel. Prominence falls as you move from what is sold toward what is metered.

P3

Type classifies, it doesn't nest

Pipeline is a value of Solution.Type; IaaS / DaaS classify the rest. Tags inside a token — never a level. Containment is Solution ⊃ Product ⊃ Feature ⊃ Usage.

P4

Reuse lives below the Product

Features are shared across Products — the platform's cluster-for-reuse. That removes any need for a Blueprint tier above Products.

06

Do & don't

Do

  • Keep Solution names in source → destination form
  • Carry Type on Solution, IaaS / DaaS on the rest
  • Bill at Usage — every Product emits a match plus any microtransaction
  • Treat this spec as canonical; bring surfaces into conformance
  • Don't

  • Put white text on the #5491E6 brand stop
  • Treat Pipeline or Feature as something other than what it is — a Type, a tier
  • Color-code IaaS vs DaaS by hue alone
  • Surface Feature to customers before it earns prominence
  • 07

    Where the token lives

    One object, four surfaces. This spec is the source; each surface conforms to it. The pill that labels a Product on the website is the same defined term that prices on the rate card, lines on the usage statement, and is referenced in the Order Form.

    Website

    Labels by Solution and its Type; Feature stays hidden initially.

    Rate card

    Type · Service · Product / Feature / Usage ID · Cost / Call.

    Statement

    UsageIDs render as lines with counts and fees.

    Order Form

    The canonical IDs are the defined contract terms.