Cortex for Allvue
The technical questions Allvue's architects raised in the review call, answered as documentation. Each page takes one question, answers it against the cortex build named in the header, and tags every claim with where it stands today: what runs in production, what exists in part, and what is not built. The pages were written from the platform's source code and its product documentation, not from a sales deck, so the tags are the point: an architecture review should be able to hold us to them.
The questions
| Question from the review | Page | Standing in one line |
|---|---|---|
| What exactly gets deployed? Project, workflow, container, server, REST service? | Deployment and runtime architecture | Available The unit is a container image per app service, exported as ordinary source with compose, Kubernetes, Container Apps, CI and a runbook. Cortex is not needed at run time. |
| Can Allvue enforce authentication, authorization and identity centrally, for every generated service? | Security and identity reference architecture | Partial Identity, RBAC and ABAC, tenant policies, secrets and audit exist on the platform; building generated services against Allvue's own provider is a build pattern today, not a platform switch, and end-user token exchange is not built. |
| What is "the harness"? What do the words mean? | Terminology | Available One sheet. The word harness is retired from our customer-facing language. |
| What happens when a developer writes the code by hand? What is the source of truth afterwards? | Developer code and generated code | Partial Edits made inside cortex are the source the next change starts from and requirements are re-derived from the live code; commits made in the exported repository do not flow back. |
| Can behaviour change without breaking the APIs other systems integrate with? | API contract and version governance | Partial Contracts are enforced as requirement-linked tests that gate every promotion; a schema-diff gate and semantic API versioning are not built. |
| How does one generated product serve many Allvue customers? | Multi-tenancy | Partial Dedicated per customer and shared with tenant row policies are supported; the hybrid model is the application's own design. |
| Why cortex rather than a code generator plus an agent framework? | Positioning | The answer Allvue gave themselves at the end of the call, made precise. |
| What would a hands-on evaluation look like? | Hands-on evaluation | Three exercises that exercise exactly the points above, with what each one proves. |
How to read the pages
Every page has the same shape: the question as it was asked, the short answer, the mechanism with its standing tags, and a closing section on what is not in place and what we propose. Where a page shows a file or a command, it is taken from an actual export of a project on the platform. Where a page names a runtime or a library, it is the one the platform uses, not an example.
The product documentation these pages build on is at docs.cortex.mindshine.com; the operational controls and policies are on the trust center. These pages are the Allvue-specific layer on top, and they will be updated as the items marked partial or not built change standing.