Platform concepts and object model
A deployment contains workspaces. Each workspace contains applications. Each application owns its metadata, facts, security policies, calculations and durable work. Use the stable workspace and application IDs returned by discovery when constructing a program. An application display name is unique within its workspace.
What application creation installs
The workspace-level workspace.application.create takes an applicationId, a display name and kind: "multidimensional". It creates eight sparse role axes: Account, Entity, Year, Period, View, Value, Scenario and Data Type. Each starts with an editable semantic description and no business members. Users define hierarchies, scenarios and categories for their application. Data Type describes application meaning; physical numeric, text and detail validation stays authoritative. Role names do not activate hidden accounting behavior. The operation grants the creating workspace administrator application-level Administrator on the new application.
From model to result
- Define members, relationships and calendars in application metadata. Add a Custom axis when the business model needs another coordinate. Model role names give the engine a common vocabulary. Calculation and accounting behavior comes from configured rules and policies.
- Build a complete fact coordinate from member IDs. For example, the disposable sample has nine axes with
Account=InputA,Entity=PointA,Year=Y2027,Period=P01,View=Input,Value=Raw,Scenario=Actual,DataType=InputDataandCustom01=ItemA. The fixture seeds this coordinate with10.00000000before the example write; read it through MCP to verify the current fixture. - Use a bounded selection or grid to inspect facts. Use registered operations to compose rules, workflows and schedules. Follow the corresponding job or receipt to confirm which effect committed at which revision.
See Workspaces and applications for the first-application workflow and Identity and isolation for the authority at each boundary.