Platform

Overview of the platform’s main building blocks (projects, modules, entities, UI, dashboards, rules and permissions).

Madrix is a platform for designing, generating and operating enterprise apps with AI.

Use this page as a mind map. It helps you navigate the blocks and flows.

Shortcuts:

• Generate and iterate in the chat: AI Chat Mode

• Advanced settings (backend + scaffold): Editor Mode

• Project settings: Project Settings

• Runtime settings (security, auth, etc): Runtime Settings

• Connect with your stack: Integrations

End-to-end flow (the “happy path”)

1. Login to the platform.

2. Open the Home.

3. Enter Projects and create/select a project.

4. Generate and evolve via AI Chat (with approval checkpoints).

5. Test in the Preview with Run.

6. Deploy with Publish (when you want Cloud).

If you want a step-by-step with ready prompts: Start here.

Interface map (where things are)

Login

Platform entry. After login, you land on the Home.

Home

Starting point. Usually you do:

• Select a recent project.

• Create a new project.

• Open global settings (user/organization).

Projects

A Project is the “container” of your app. It stores:

• Structure (modules, entities/components, fields, scripts).

• Generated UI (screens, routes, menus).

• Settings and environments.

Project Editor (top bar)

This is the area where you switch between generate and edit.

Common items:

• Project name

• Mode toggle: AI Chat ↔ Editor

• Run: opens/refreshes the app Preview

• Publish: deploys to Cloud environment (when configured)

• Home: returns to Home

• Notifications

• User/Organization settings

User / Organization Settings

Where preferences and organization context live (e.g.: permissions, access, etc).

Selected language

Controls interface texts. Also interacts with translations like pt-BR, en, etc.

Essential concepts (short definitions)

• Project: the entire app (code, data, settings and deploy).

• Module: a functional domain (e.g.: Sales, Tasks, Finance).

• Entity / Component: your main “object” (becomes a table in the database).

• Field: entity attribute (type, required, unique, picklist, etc).

• Relationship: connection between entities (1-N, N-N).

• Script: backend business rule (e.g.: validation and automation).

• UI: generated screens, routes, menus and forms.

• Dashboard / Report: managerial view and analyses.

• Permissions (RBAC): who can see/do what.

How AI generates systems in Madrix (mental model)

The flow tends to be this:

1. You describe objective, entities and rules in the prompt.

2. The platform generates a specification for you to approve.

3. After approval, agents generate backend + UI + project resources.

4. You test in the Preview and request incremental changes.

Practical tip: treat the specification as a “contract”. It reduces rework.

Common flows (when to use each mode)

AI Chat (large and iterative changes)

Use when you want to:

• Create an app from scratch.

• Add entire modules and entities.

• Refactor rules or flows.

• Request changes in “business language”.

Open: AI Chat Mode

Editor (“surgical” adjustments and fine control)

Use when you want to:

• Adjust fields, relationships, menus and event scripts.

• Understand the generated frontend scaffold.

• Resolve details the chat did not handle well.

Open: Editor Mode

AWUs (Agentic Work Units)

An AWU is the consumption unit for agentic work. In practice, it grows with:

• Scope of the request (number of modules/entities/screens).

• Number of iterations (changes that rewrite a lot).

• Complexity of rules, integrations and permissions.

Best practices to consume less:

• Start with a smaller prompt and evolve in steps.

• Approve the specification before generating.

• Make changes in small, testable “batches”.

Wide and vague change (“redo everything”) usually consumes more and breaks more things.

Limits (limits, best practices and anti-patterns)

Use as a guardrail to have more predictability.

Best practices:

• Write prompts with objective + entities + rules.

• Prefer consistent names. Avoid synonyms for the same thing.

• Request changes in checklist format. This reduces ambiguity.

• Test in the Preview right after each batch of changes.

Anti-patterns:

• Requesting “a complete ERP” in a single prompt.

• Mixing many domains in the same first step.

• Changing names and structures “in bulk” without validating impact.

• Deploying without validating the Preview and basic permissions.

Next steps

• Want to learn by doing: Hands-on Tutorials

• Want to see real cases: Demonstrations

• Stuck on something: Troubleshooting