Infinite Cabinet

A field report on the InfiniteCabinet project — what it is, what we pull into REV.health, and what we leave behind. InfiniteCabinet is the upstream "jig" that produced REV.health's IC framework; this page makes the lineage explicit and books the remaining work.

What InfiniteCabinet is

InfiniteCabinet is a metadata-driven, template-generated, end-to-end enterprise application builder. You hand it a JSON Application Model Interface (AMI) describing a single business noun (an Invoice, a Customer) plus a companion rules file, and its code-generation engine produces a full stack: Cosmos / EF Core schema, .NET 9 minimal-API CRUD endpoints, Angular 21 standalone components packaged as Web Components, validation middleware, OpenAPI spec, xUnit / Vitest tests, and HTML docs — in a fixed pipeline of DB → API → Components → Tests → Docs → Deploy. Three pillars hold the model up: a numeric 0–100 RBAC engine with four permission scopes; a strict version format break.feature.bug.buildtimestamp with cascade deployment that forbids prod from running ahead of lower envs; and a 14-rule "hard rules" contract that the generator (not policy) enforces (OrgID on everything, soft delete only, audit columns auto-injected, max 500 lines per file, API enforces referential integrity because Cosmos has no FKs).

Why it matters to REV.health

REV.health's existing IC framework is already a re-skinned, clinical-aware fork of the InfiniteCabinet generator. Every module page in PRD v2 (clinical-doc, scheduling, rcm, …) implicitly assumes IC-style AMI generation. What is missing is the provenance: which patterns came directly from InfiniteCabinet, which we changed for HIPAA / FHIR / multi-org data sharing, and which we never adopted. This page closes that loop and captures the artifacts the v1 gap report flagged as P0 (per-module IC-application overrides, RBAC matrix per module, versioning worked examples). Anything ADOPT or ADAPT is a candidate copy/port job; anything INSPIRE or DROP needs a one-time decision and then stays decided.

The "Infinite Cabinet" jig

InfiniteCabinet treats application code the same way. The AMI schema is the workpiece (changes per app: Invoice today, Encounter tomorrow). The CodeGenerationOrchestrator + templates + hard rules are the jig: they hold the schema in place and machine it through a fixed sequence of cuts (DB → API → Frontend → Tests → Docs). Two operators feeding the same AMI to the same jig get byte-identical output, same audit columns, same OrgID partitioning, same RBAC hooks, same component tag names — because the generator, not the developer, enforces the invariants.

For REV.health that translation is straight: Encounter, Appointment, Claim, PriorAuth, Prescription, Referral are workpieces. The jig guarantees that EncounterID is a Short GUID, that OrganizationID partitions the container, that audit fields are present, that the generated component is ic-ng21-clinical-doc-detail-encounter, and that no junior developer can field-rename in prod without an EditAMI (level 90) grant. Hand-written exceptions are still possible, but they are visible: anything not produced by the jig stands out in code review.

Artifact inventory

Each row is one re-usable thing in InfiniteCabinet. Verdict is one of:

AMI schema model

source: src/IC.Models/Ami/AmiSchema.cs + AmiEntity.cs + AmiField.cs + AmiFieldType.cs

public class AmiSchema : BaseEntity
{
    public string  Name { get; set; }            // "Invoice"
    public string? Description { get; set; }
    public string  RootNoun { get; set; }        // "Invoice" — apps are nouns
    public string  Version { get; set; }         // "1.3.0.20260401120000"
    public List<AmiEntity>          Entities { get; set; }
    public List<VersionHistoryEntry> VersionHistory { get; set; }
}

public class AmiField
{
    public string  Name { get; set; }
    public string  Type { get; set; }              // AmiFieldType constants
    public bool    Required { get; set; }
    public bool    IsPrimaryKey { get; set; }
    public bool    IsForeignKey { get; set; }
    public string? FkTargetSchema { get; set; }    // "Customer"
    public string? FkTargetEntity { get; set; }
    public string? ComponentMapping { get; set; }  // override default tag
}

Code generation orchestrator

source: src/IC.CodeGen/CodeGenerationOrchestrator.cs

Five-phase pipeline with strict ordering. Adopt the orchestrator skeleton verbatim, then swap in REV-specific templates per phase.

graph LR
  AMI["AMI schema
(+ optional Rules)"] --> P0["Phase 0
Parse & validate
path-safe names"]
  P0 --> P1["Phase 1
Database
(Cosmos / EF Core)"]
  P1 --> P2["Phase 2
API
(CRUD + Validation + OpenAPI)"]
  P2 --> P3["Phase 3
Frontend
(Grid / Form / Detail)"]
  P3 --> P4["Phase 4
Tests
(CRUD + Validation + Contract)"]
  P4 --> P5["Phase 5
Docs
(SchemaDoc + ApiDoc)"]
  P5 --> OUT["GenerationResult
+ 500-line check
+ path-traversal guard"]
  

Why adopt the skeleton: the orchestrator already enforces three things we want in every REV codegen run —

1. IsNameSafeForPath() rejects .., slashes, leading non-letters before writing anything (HIPAA-relevant: prevents tenant boundary escape via crafted entity names).
2. IsPathUnderBase() resolves the absolute path and verifies it stays under the output dir — defence in depth.
3. MaxLinesPerFile rejects any generated file over the rule-9 threshold (default 500). Forces template authors to split.

Integration sketch:

var orchestrator = new CodeGenerationOrchestrator(new CodeGenOptions
{
    SelectedPhases   = { GenerationPhase.Database, GenerationPhase.Api,
                         GenerationPhase.Frontend, GenerationPhase.Tests,
                         GenerationPhase.Docs },
    MaxLinesPerFile  = 500,
    TemplateSet      = "rev-health-v1"   // REV-specific templates
});

var result = orchestrator.Generate(encounterSchema, encounterRules);
if (!result.Success) throw new CodeGenException(result.Errors);
CodeGenerationOrchestrator.WriteToDirectory(result, "out/clinical-doc/");

RBAC engine (0–100)

source: src/IC.Security/

The numeric scale — identical to the one already documented in ic-reference, but with InfiniteCabinet's two extra layers:

public static class PermissionLevel
{
    public const int NoAccess       = 0;
    public const int Read           = 1;
    public const int Write          = 51;
    public const int Deploy         = 70;
    public const int ManageFeatures = 80;
    public const int EditAmi        = 90;
    public const int Admin          = 100;
}

public class PermissionGrant
{
    public string AppName     { get; set; } = "*";     // "scheduling", "rcm"
    public string Environment { get; set; } = "*";     // "Dev", "QA", "UAT", "Prod"
    public string EntityName  { get; set; } = "*";     // "Appointment"
    public string Scope       { get; set; }            // Object / Row / Column / ComplexAlgorithm
    public int    Level       { get; set; }            // 0–100
    public bool   Recursive   { get; set; } = true;
    public string TargetType  { get; set; } = "RoleGroup"; // User | Role | RoleGroup
    public string TargetId    { get; set; }

    // Column scope
    public List<string>? RestrictedFields { get; set; }
    public int?          FieldVisibilityLevel { get; set; }

    // Row scope
    public string? RowFilterExpression { get; set; }

    // ComplexAlgorithm scope
    public string? AlgorithmId { get; set; }
    public string? AlgorithmParameters { get; set; }
}

L1 / L2 / JTable components

source: libs/components/src/lib/

InfiniteCabinet ships 17 ready Web Components, all ViewEncapsulation.ShadowDom, all mobile-first, all framework-agnostic at consumption time:

export const DEFAULT_COMPONENT_MAP: ComponentMapping = {
  String:   'ic-ng21-core-1-text-input',
  Text:     'ic-ng21-core-1-textarea',
  Int:      'ic-ng21-core-1-number-input',
  Decimal:  'ic-ng21-core-1-number-input',
  Money:    'ic-ng21-core-1-currency-display',
  Bool:     'ic-ng21-core-1-boolean-toggle',
  DateTime: 'ic-ng21-core-1-date-picker',
  GUID:     'ic-ng21-core-1-guid-display',
  Enum:     'ic-ng21-core-1-dropdown',
  Address:  'ic-ng21-core-1-address-form',
  Phone:    'ic-ng21-core-1-phone-input',
  Email:    'ic-ng21-core-1-email-input',
};

Breaking-change detector

source: src/IC.Models/Ami/BreakingChangeDetector.cs

Versioning & cascade deploy

source: rules/versioning.md + rules/hard-rules.md (rules 1, 6, 7, 8, 9)

Glossary & naming

source: rules/naming-conventions.md + glossary terms scattered across docs/ and context/

Cross-module impact

What changes in each REV.health module if we land the ADOPT and ADAPT artifacts above:

Explicitly dropped (and why)

REV.health-built components (IC adoption candidates)

The following components were built for REV.health during the 2026-06-02 session and are structured to be lift-able into the Infinite Cabinet component library. They are not sourced from InfiniteCabinet but follow IC conventions (props-driven, single-purpose, CSS-token-only styling).

Open questions for human review

1. Permission level overlap. InfiniteCabinet defines Write=51, Deploy=70, ManageFeatures=80, EditAmi=90, Admin=100. ic-reference defines Patient=10, Clinical-Read=30, Clinical-Write=50, Administrative=70, System-Admin=90, Platform-Op=100. Need a single merged ladder — or an explicit decision that the two scales are namespaced (platform-ops vs clinical).
2. Audit field naming. Source uses OrgID, LastUpdatedDateTimeUTC, LastUpdatedByUserID, IsSoftDeletedBool. REV.health data-model uses OrganizationID, CreatedDateTimeUTC, ModifiedDateTimeUTC, ModifiedByUserID. Pick one; update AuditFieldInjector accordingly.
3. BaseEntity inheritance vs duck-typed audit. InfiniteCabinet uses class inheritance (: BaseEntity). REV.health AMI is JSON-only and currently has no equivalent base type. Add a "$schema" reference or an explicit base AMI template?
4. FHIR mapping placement. Generate a FHIR resource mapper in Phase 2 (API) or as a separate Phase 6? Affects whether external systems can hit the generated FHIR endpoint directly.
5. Rules companion lifecycle. InfiniteCabinet bumps rules independently. For payer/eligibility rule churn this is right. For Prior-Auth state machine changes that imply schema changes (new statuses), should the rules bump cascade-bump the schema?
6. Tag prefix convention. Keep ic-ng21- or switch to rev-ng21- for clinical components? Affects every component tag REV.health ships.
7. Build-once-run-everywhere & PHI. Same component bytes in Dev and Prod is fine, but a Dev env that talks to Synthea fake data must never resolve to a Prod Cosmos DI config. Need stronger guarantees than "the import map is correct".
8. Cascade deployment with regulatory holds. Cascade rule says deploying to UAT promotes Dev / QA automatically. What happens when prod is held back for ONC / EHNAC certification? Need an explicit "frozen prod" exception.

Cross-links

• IC Application Reference — the downstream surface that this page back-fills.
• Data Model — where the AMI schema, BaseEntity audit fields, and ShortGuid convention land.
• Encounter Type System — concrete example of an AMI schema that benefits from AMI Rules companion + BreakingChangeDetector.
• Architecture — where CodeGenerationOrchestrator and cascade deployment land.
• Decisions — cross-reference the eight InfiniteCabinet DEC entries in context/decisions-log.md for ADRs we may want to promote into the REV.health DEC-RH series.
• v1 Gap Report — the P0 gaps "PMR Deep Exemplar", "Per-module IC-application pages", and "RBAC matrix per module" are partially served by the artifacts adopted on this page.
• Roadmap & Gantt — the ADOPT / ADAPT effort estimates above should feed the platform-level Gantt for Phase 1.