Describe the system you need. Governed agents build it.
DXMachine generates complete business applications from a structured spec: related data, forms, state machines, reports, dashboards and value streams. Every change is authorized, attested and reversible.
The AI agents that do the building work under the same identity, approval and audit rules as your people. When an examiner asks who changed a rule, on whose authority and when, the answer is already on the record.
Under development DXMachine is not yet generally available. We are building it with a small development advisory of regulated organizations. See where it stands →
Agents are joining your workforce. Give them an organization.
Every workforce has always needed the same things: a building with a front desk, roles and sign-off authority, institutional memory, honest books, and the work itself. An agent workforce needs them too. General Reasoning provides each one as a single governed operating model, and DXMachine is where the work happens.
Every layer follows the same rule, set out in the CRC standard we publish: fewer surfaces, fewer edges, and no edge crossed without authority. And every line of source is open to you. Why edges matter →
Regulation didn't invent these controls. Scale did.
Scoped authority, separation of duties, a record nobody can quietly edit: regulated industries adopted these because at high stakes, trust has to be proven. Human workforces let most of the business skip them, because people are slow, personally accountable, and can explain what they did. Agents are none of those. Every business that wants a real agent workforce, regulated or not, will need the same controls. The General Reasoning stack is those controls, built in.
Autonomy needs bounds
You can only hand an agent more work when you can limit what it may do. Without scoped authority, autonomy stays capped at whatever you'd tolerate going wrong unseen.
Speed needs a record
When an agent makes thousands of changes in an hour and one is wrong, logs won't tell you which. An attributed record finds it, reverses it, and proves the rest were sound.
Agents don't stay in their lane
An agent working an unregulated backlog can still reach identity, source code and customer data. The domain may be unregulated; the edges it crosses usually aren't.
Your customers will ask
Customers, insurers and auditors already push control requirements down supply chains. Proof of how your agents are governed is becoming a condition of doing business.
Everything a business application needs, generated and governed
Most organizations run their regulated processes in spreadsheets, shared inboxes and one-off database apps that nobody can audit. DXMachine replaces them with real applications built on one governed foundation.
Related records, done properly Working
Parent and child records at any depth, lookups and composite keys. Uniqueness and referential integrity are enforced when a record is saved, not left to a cleanup job.
A forms designer Working
Layouts, validation, and child records shown inline on the parent's form. Form designs are versioned, so changing a form is a recorded event, not a silent edit.
State machines Next
Every record type has explicit states and allowed transitions. Each transition carries its own role requirements, approvals and evidence.
How transitions work →Reports and dashboards Planned
Queries, summaries and live views, including kanban and flow boards driven directly by record state, so the board can't drift from the data.
Value streams Next
Governed pull from investment to release, with WIP limits, aging controls and gate reviews.
See the Governed Backlog →Stop the line Working
Andon controls halt an application, a route or an agent instantly. Stopping and restarting are both attested events.
Working running in development builds · Next the current build stage · Planned scheduled after it. Roadmap →
State machines are the rules, not a diagram of them
In most platforms a process flow guides the user through a screen, and the underlying record can still be edited into any state. In DXMachine the state machine is enforced at the record. A transition that isn't defined can't happen, whether it comes from the form, the API or an agent.
| Transition | Who may make it | What must be true | Result |
|---|---|---|---|
| Received → Triaged | Intake analyst | Classification code assigned | Allowed · attested |
| Triaged → Investigating | Supervisor | Named investigator assigned | Allowed · attested |
| Investigating → Resolved | Investigator. An agent may draft findings; a human signs. | Findings and evidence attached | Allowed · attested |
| Resolved → Closed | Principal, never the investigator | Customer response sent | Allowed · separation of duties checked |
| Investigating → Closed | No one | Transition not defined | Refused · refusal recorded |
Because the lifecycle is data rather than code, it is versioned like everything else. You can see exactly which rules were in force on the day a record moved, and a change to the rules goes through its own approval.
Generate it with a wizard. Keep changing it for the life of the app.
The App Configurator is where every DXMachine application begins. It works the same way as our Industry Configurator: a short guided wizard. It starts from the industry personality you already built, so the processes you selected become candidate applications and your terms become the names. You describe what the app has to do, governed agents draft the specification, and you review it before anything runs.
Review the spec the agents drafted
The spec is a readable record of what the app will be: each row declares a table, a relationship, an index, a state, a separation-of-duties rule or a report. Nothing is published until an owner has approved it.
| Kind | Name | Definition | Notes | |
|---|---|---|---|---|
| 1 | Hub | complaint | customer · account · received_at · channel · category | Primary record |
| 2 | Child | communication | complaint 1 → n · direction · sent_at · body | Shown inline on the complaint form |
| 3 | Child | remediation | complaint 1 → n · action · amount · approved_by | Requires approval to save |
| 4 | Index | complaint_unique | (customer, account, received_at) unique | Blocks duplicate intake |
| 5 | States | complaint.lifecycle | Received → Triaged → Investigating → Resolved → Closed | See transition rules |
| 6 | SoD | close_rule | closed_by ≠ investigated_by | Separation of duties |
| 7 | Report | aging | Open complaints by state × age bucket | Dashboard and kanban |
| 8 | Report | quarterly | Counts by category and product, per quarter | Regulatory statistical filing |
Early accessThe App Configurator is open: build a spec from an example or from nothing, review it, and download the application file. Generating the running application from that file is the next release. Its first target is Chandra Passport, General Reasoning's own access product.
The spec is where an app starts, not where it stops
Regulations change, and so do the processes built on them. Every mechanism used to generate a DXMachine app stays available inside it for as long as it runs. You don't regenerate the app or schedule a migration project. You change it in place, through the same approvals, and every version stays on the record.
Versioned forms and fields Working
Add or retire fields by publishing a new form version. Records keep the version they were captured under, so upgrading a form never requires a data migration, and old records still read exactly as they were entered.
Lifecycles and rules that evolve Next
States, transitions and separation-of-duties rules are versioned data. You can see which rules applied on the day a record moved, and a rule change goes through its own approval.
Changes proposed, never slipped in
People or governed agents can propose a change to a live app. It arrives as a change set with a diff against the running version, and it takes effect only when a named owner approves it.
Build your own. Start from an example.
Every DXMachine application starts as a spec in the App Configurator. Start from nothing, start from your industry personality, or start from one of these examples and change whatever doesn't fit. Each example page shows the full starting spec and its lifecycle rules.
Governed Backlog
Four-level pull from investment to release, enforced WIP limits, and change evidence for SOX and SOC 2.
See the example →Complaints Register
Intake, investigation, remediation and quarterly reporting, with separation of duties at close.
See the example →Change Management
Change boards, separation of duties and emergency changes, with a control test that runs as a query.
See the example →HR Cases
Employee relations cases isolated by design, with independent investigators and every access attributed.
See the example →SOC 2 Control Room
Controls mapped to the Trust Services Criteria, evidence attested at capture, and a bounded seat for your auditor.
See the example →88 starting points
Browse starting points across 12 domain groups in the App Configurator, from branch inspections to POA&M tracking, or start from nothing.
Open the App Configurator →More examples are on the way for every domain below. See the full list →
Agents build under the same rules as people
Every AI agent in DXMachine is a named principal with a bounded capability envelope. An agent can propose a schema change, draft a form or advance a work item, but only as far as its role allows, and through the same state machines and gates as everyone else.
Agents bolted onto a platform
- The agent borrows a user's session or a service account.
- Its changes look the same in the log as a human's, or don't appear at all.
- The platform's configuration can be changed by whoever administers it.
- After an incident, someone rebuilds what happened from logs.
Agents in DXMachine
- Each agent has its own identity, role and capability limits.
- Every action is attributed to the agent and to the human it acts for.
- Changes to the application itself pass through approval gates.
- What happened is on the chain at the moment it happens.
Alongside your ERP, not instead of it
You don't have to rip anything out. Keep your ERP and CRM as systems of transaction. Move the regulated processes that have to be proven, such as complaints, change control, inspections, exceptions and approvals, onto DXMachine, where every step is attested.
Processes over existing data
A DXMachine workflow can reference records that live in another system, and it attests every decision made about them.
PlannedConnectors for major ERP and CRM platforms
Start from your current model
Read an existing entity model into an App Configurator spec, then generate a governed version of it.
Planned
Full source access
Your license includes the source for the whole stack and for every app you generate, to examine, audit and modify. How licensing works →
Closed source, with every line open to you.
SaaS keeps its code out of sight. Open source publishes it to everyone, attackers included, along with every dependency anyone can push to a public registry. General Reasoning takes a third path. The entire stack is closed source and owned by General Reasoning, including the code generated for your applications. As a licensee, you have full access to that source, and you are free to examine, audit and modify it.
No black boxes
Your security team and your auditors can read every line: DXMachine, Chandra Enterprise, AletheiaGraph, AegisGenera, and the code generated for each of your applications. You verify it for yourself instead of trusting a vendor's report.
Change it to fit
Your license lets you modify the source to fit your environment and your controls. You aren't waiting on a vendor's roadmap to close a gap your examiner found.
Closed, so it's controlled
Public package registries are now a favored attack path, and agents install dependencies faster than anyone can vet them. A closed-source stack built from vetted code takes that edge away. No build pulls unreviewed code from the internet.
One application shape, repeated across every function
Most compliance software is the same few things over and over: a register, a lifecycle, approvals with separation of duties, expiry dates and evidence. DXMachine builds that shape once, properly governed, and generates it for each domain. These are the categories where it fits best.
Agile backlog and portfolio
A four-level backlog, WIP-limited kanban, epic and feature lifecycles, dependencies and gate decisions. Every change is attested, so the backlog doubles as change-control evidence for SOX and SOC 2.
See the example →Established toolsBroadcom Rally · Azure DevOps Boards · Jira and Jira Align
Change, incident and request
Change requests with approval boards and separation of duties, incidents, problems and service requests. Change management is a state machine with evidence gates, and auditors test it every year.
See the example →Established toolsServiceNow ITSM · Jira Service Management · BMC Helix ITSM
HR cases and employee lifecycle
Employee relations cases and investigations, onboarding and offboarding checklists tied to access, policy acknowledgments and leave approvals. Sensitive cases stay isolated by design.
See the example →Established toolsServiceNow HR Service Delivery · HR Acuity
Access requests and reviews
Access requests, certification campaigns and separation of duties. This is Chandra Passport's own admin plane, and the first application we are generating.
Established toolsSailPoint · Saviynt
Risk, issues and controls
Risk registers, issues and actions, control testing and policy attestation.
Established toolsOptro (formerly AuditBoard) · LogicGate · Archer
CAPA and change control
Corrective actions, nonconformances and change control are state machines with evidence gates.
Established toolsOctave Reliance (formerly ETQ) · MasterControl · TrackWise
Incidents and corrective actions
Incident, investigation, action and verification, with every step attributed.
Established toolsIntelex · Cority · Enablon
Attestations and disclosures
Annual attestations, conflicts of interest, gifts and entertainment, and outside activity disclosures.
Established toolsMyComplianceOffice · StarCompliance
Vendor management
Vendor registers, questionnaires and periodic reviews with expiries.
Established toolsNcontracts (incl. Venminder) · OneTrust
By domain
Regulated or not, every domain below runs on the same governed foundation. Where a regulator sets the rules, the Industry Configurator already models them; project management, IT service management and HR run under your own policies, with the same attestation. For each domain we list the established tools in the category, and just as deliberately, what stays in your existing systems.
| Domain | Applications DXMachine generates | Established tools in the category | Stays in your existing systems |
|---|---|---|---|
| Financial services In beta at BlackRock | |||
| FINRA / SEC advisers | Complaints log (Rule 4530); gifts and entertainment; outside business activity and private securities transaction disclosures; annual attestations; marketing review approval; branch inspections | MyComplianceOffice; StarCompliance; ComplianceAlpha (ACA); Red Oak; RegEd | Communications archiving; trade surveillance |
| FFIEC banking | Vendor management; complaint management; policy management; exam findings tracking | Ncontracts (incl. Venminder); Wolters Kluwer | Core banking; AML transaction monitoring; loan origination |
| SIFI / G-SIB | One bounded module, such as issues and actions, policy attestation or regulatory change, run as a pilot | Archer; MetricStream; IBM OpenPages; ServiceNow IRM | Enterprise-wide GRC platform |
| Lloyd's syndicates | Delegated-authority audit findings and remediation; regulatory attestations | — | Placement, claims and market accounting |
| Conglomerates / sovereign wealth | Portfolio-level issues and actions; policy attestation; subsidiary certifications | Archer; MetricStream; Diligent (entity management) | Consolidation and financial close |
| ASC 606 | Contract review and five-step judgment memos with approvals | No direct equivalent; revenue engines sit beside it | Revenue calculation engines |
| Healthcare and life sciences | |||
| HIPAA | Access-request log; BAA register; breach incident workflow; risk analysis register; training attestations | Compliancy Group; Clearwater | Electronic health records; access-log analytics (e.g. Imprivata FairWarning) |
| Joint Commission / CMS | Policy management and attestation; incident and event reporting; credentialing with expirations; survey readiness | NAVEX One PolicyTech; RLDatix; symplr | Clinical systems |
| Hospital compliance program | Hotline cases and investigations; conflict-of-interest disclosures; compliance committee actions; OIG exclusion screening (with governed data feeds) | NAVEX One | The exclusion databases themselves |
| Controlled substances / DEA | Diversion investigations; discrepancy resolution; theft-and-loss (DEA Form 106) case tracking; waste-witness exceptions | BD HealthSight Diversion Management; Imprivata diversion analytics | Dispensing cabinets and their surveillance analytics |
| Clinical laboratory / CLIA and CAP | QC failures and corrective action; proficiency testing results; personnel competency assessments; procedure sign-off | MediaLab (Vastian) | Laboratory information system; instruments |
| Health plans / Medicare Parts C and D | Grievances; coverage determinations and appeals against CMS timeliness rules; delegated-entity oversight; program audit universes | Inovaare; Mirra Health Care | Claims adjudication; enrollment |
| FDA / 21 CFR Part 11 | CAPA; deviations; change control; complaints, with the attributed, immutable records Part 11 asks for | Veeva Vault QMS; MasterControl; TrackWise (Honeywell); Octave Reliance (formerly ETQ) | Validated systems, until our computer system validation package is published |
| Medical devices / QMSR and ISO 13485 | Complaint handling with MDR reportability decisions; CAPA; design review and design history file approvals; supplier controls | Greenlight Guru; MasterControl | PLM and CAD; ERP |
| Clinical research / GCP | Protocol deviations; delegation-of-authority log; site training records; monitoring findings and follow-up | Florence eBinders; Veeva SiteVault | EDC, randomization and CTMS |
| Energy, industry and government | |||
| Energy / NERC CIP | Access reviews; change tickets; incident response plan records; evidence binders | AssurX; Archer or ServiceNow configured for CIP | Device configuration monitoring |
| Mining / MSHA / ICMMIn beta at Newmont | Citations and abatement; incidents; permit register; tailings-standard evidence; corrective actions | Enablon (Wolters Kluwer); Intelex; Cority; Sphera; VelocityEHS | Operations telemetry |
| Manufacturing / IATF 16949 | CAPA; nonconformance reports; 8D; PPAP approval; supplier corrective actions; audits | Octave Reliance (formerly ETQ); MasterControl; Intelex | MES; high-volume statistical process control; PLM |
| FMCSA / DOT | Driver qualification files with expirations; inspection defect repair; clearinghouse query log; accident register | J.J. Keller Encompass; Tenstreet | ELDs and telematics |
| Municipal / state audit | Single-audit findings and corrective action plans; grant compliance; council approvals; tax appeal cases | Tyler Technologies; OpenGov | General ledger; tax billing |
| FedRAMP / CMMC | POA&M tracking; control narratives; monthly continuous-monitoring submissions; evidence collection | Telos Xacta; RegScale | Automated cloud scanning |
| Technology, operations and risk | |||
| SOC 2See the example → | Manual control tracking; policy attestation; vendor reviews | Vanta; Drata; Secureframe | Automated evidence from cloud, identity and code platforms |
| IT risk | Risk register; control testing; issue remediation; vendor questionnaires | Optro (formerly AuditBoard); LogicGate; Archer; ServiceNow IRM | Little. A strong fit end to end |
| IT service management | Change requests with approval boards and separation of duties; incidents and problems; service requests; change-control evidence for SOX ITGC | ServiceNow ITSM; Jira Service Management; BMC Helix ITSM | CMDB and discovery; monitoring and observability |
| Human resources | Employee relations cases and investigations; onboarding and offboarding tied to access; policy acknowledgments; leave approvals | ServiceNow HR Service Delivery; HR Acuity | HRIS and payroll |
| Project management / agile portfolio | Portfolio and program backlog from investment to release; kanban with WIP limits and aging; epic and feature lifecycles; dependency tracking; quarterly planning; gate decision records; change-control evidence | Broadcom Rally; Azure DevOps Boards; Jira and Jira Align | Source control; CI/CD pipelines; code review |
Product names identify the category DXMachine competes in and are trademarks of their respective owners. No affiliation or endorsement is implied.
How DXMachine compares
Enterprise suites and low-code platforms are excellent at breadth. DXMachine is built for the part they can't do: proving to an examiner that the application, its rules and every action taken in it were authorized and unaltered.
| Typical enterprise suite or low-code platform | DXMachine | |
|---|---|---|
| How apps are built | Low-code designers, increasingly with AI assistance | Generated from a declarative spec by governed agents, and approved at a gate |
| Record lifecycle | Process flows that guide the screen. Records can often be edited around them. | State machines enforced at the record, whatever the entry point |
| Audit | Audit logs, often administered by the same team they audit | Hash-chained attestation of both data changes and application changes |
| AI agents | Assistants acting through user or service credentials | Agents as principals with their own grants, and every action attributed |
| Changing the app later | Schema changes become release projects with data migrations | Versioned forms and fields, changed in-app. Old records keep their version, with no migration |
| Source code | Held by the vendor and hidden from you. You rent access to a service | Owned by General Reasoning and licensed with full source access, to examine, audit and modify |
| Deployment | The vendor's cloud | Your hardware or a dedicated instance |
| Existing systems | Consolidate onto the platform | Govern the regulated processes and leave the rest in place |
Reachability is not authority
An AI adversary doesn't attack one application at a time. It builds the whole graph of your systems, identities and data flows at once, and walks the edges between them. That is why every product in the General Reasoning stack follows the CRC standard (Consolidate, Reduce, Close): fewer surfaces, fewer edges, and every remaining edge governed.
What the market offers today
- Graph databases can restrict which relationships a role may read or traverse.
- Attack-path tools map how an intruder could move, so you can see the risk after the fact.
- Agent gateways check a call at the perimeter, then trust whatever it reaches inside.
- Audit logs record what happened, in a store an administrator can change.
The General Reasoning stack
- Each organization and surface is isolated, so there are fewer edges to cross at all.
- Traversal is bounded by authority, edge class, depth and exposure, not just by what's reachable.
- Every crossing carries its grant, from the boundary gateway to the database query.
- Every crossing lands on a hash-chained record nobody can quietly edit.
The store of truth for everything
AletheiaGraph is both the stack's enterprise database (transactions, records, indexes and a native graph) and its reasoning engine, with inference and proof built in. It keeps stored, inferred and proposed facts distinct, so a conclusion is never mistaken for a record. Its query optimizer applies the CRC reachability model before cost: it chooses the cheapest plan that is permitted, not just the cheapest plan. At v1, AletheiaGraph becomes the storage engine for the entire stack, DXMachine applications included. The apps you generate inherit attested storage and governed traversal without a line of security code. aletheiagraph.com →
Where DXMachine stands
DXMachine is under development, and we would rather tell you exactly where it stands than oversell it. It runs on Chandra Enterprise, which is in beta with customers today. Each stage below makes a wider set of applications credible.
Registers and logs Working
Forms, composite indexes and validation triggers. Enough for complaint logs, gift registers, BAA registers and citation logs.
Governed workflow Building
State transitions, references between records, quorum approvals, separation of duties, a scheduler and kanban. This stage unlocks every domain above, starting with Passport.
Full platform Planned
Reporting and dashboards on AletheiaGraph, notifications and SLA timers, and governed connectors for identity sync and external data feeds.
Pricing you can model
The same three line items as the rest of the General Reasoning stack.
Platform fee
The governed stack, deployed on your hardware or a dedicated instance.
Application definition
A one-time fee for each regulated workflow or application configured for your organization.
Active engagements
A per-engagement fee that scales with the work you run, not with headcount.
Join the development advisory.
We're working with a small group of compliance, risk and quality leaders in regulated organizations. Bring the process you can least afford to get wrong. We'll specify it with you, you review early builds, and your process becomes one of the first applications DXMachine generates.