Examples standard
Standard scope
Applies to: All documentation examples, sample configurations, and walkthroughs across every scope Domain: examples Status: Active
This standard defines the mandatory fictional identity used in documentation examples across every scope this repo governs — hcs, azurelocal, and tierpoint-prodtech. Two of the three scopes already required this before it was formalized here; this document makes the rule universal and states the one boundary that matters.
The rule
All examples, sample configurations, and walkthroughs in documentation use one fictional company: Infinite Improbability Corp (IIC).
Mandatory
Never use contoso, fabrikam, adventure-works, woodgrove, example.com, or any real customer name in documentation examples. IIC only — in every repo, every example, every sample config, across all three scopes.
IIC reference card
| Attribute | Value |
|---|---|
| Full name | Infinite Improbability Corp |
| Abbreviation | IIC |
| Domain (public) | improbability.cloud |
| Domain (alternate) | iic.cloud |
| Domain (on-prem AD) | iic.local |
| NetBIOS name | IMPROBABLE |
| Entra ID tenant | improbability.onmicrosoft.com |
| Email pattern | user@improbability.cloud |
Example usages
Fictional resource group name
rg-iic-platform-01See naming.md for the full azurelocal-scope naming overlay this feeds into.
Fictional domain and email in prose
Infinite Improbability Corp deploys Azure Local clusters using IIC naming patterns, with all configuration driven from a single
config/variables.ymlfile. The deployment engineer,jane.doe@improbability.cloud, provisions the cluster fromrg-iic-platform-01.
Fictional config sample
subscription:
subscription_id: "00000000-0000-0000-0000-000000000000"
tenant_id: "00000000-0000-0000-0000-000000000000"
location: "eastus"
security:
keyvault_name: "kv-iic-platform"
azure_local:
resource_group: "rg-iic-platform-01"
cluster_name: "azlocal-iic-01"Use all-zero GUIDs (00000000-0000-0000-0000-000000000000) for any subscription ID, tenant ID, or object ID shown in an example — never a real identifier, even a low-sensitivity one.
The boundary: examples vs. real environment names
This is the one distinction that matters most, and it must be stated plainly.
IIC governs documentation examples only. It does not apply to real Key Vault secret naming or real environment names. HCS's Key Vault standard actively uses real environment names as part of the KV secret naming pattern — tplabs, tppoc, tpdemos, hcsprod, and others — because those are real infrastructure identifiers, not documentation placeholders. Secret names like tp-tplabs-domain-admin-password are real, live secret names in a real vault; they are not examples to be sanitized.
Real environment names must never appear in prose or example documentation. If you are writing a walkthrough, a sample config, a tutorial, or any other piece of documentation prose, use IIC. If you are documenting or referencing an actual secret, an actual resource, or an actual environment that exists in kv-hcs-vault-01 or any other HCS-managed vault, use the real name as recorded in the Key Vault standard and the secret inventory.
| Context | Use |
|---|---|
| Documentation walkthrough, tutorial, sample config | IIC (improbability.cloud, rg-iic-*, kv-iic-*) |
| Real secret name in the secret inventory | Real env-name (tplabs, tpdemos, tpprod, hcsprod, etc.) |
Real resource name in docs/identity/ or an architecture doc describing actual infrastructure | Real name |
| Blog post, community demo, public-facing training material | IIC |
This boundary is also why tierpoint-prodtech-scoped documentation stays off the public HCS standards site — see docs-platforms.md. That scope's documentation legitimately references real environment names as part of its normal operation, which is exactly the content this standard says must never appear in public-facing example prose.
Enforcement
- PR review — reviewers flag any use of
contoso,fabrikam, or other non-IIC fictional names in documentation examples - Config validation —
variables.example.ymland equivalent template files use IIC naming in all placeholders - CI — linting rules may flag non-IIC fictional company names where configured
Related
- Naming standard — the
azurelocal-scope naming overlay built on IIC patterns - Key Vault standard — real environment-name registry (the boundary this standard defers to)
_scopes/README.md— three-way scope model and public/private site split