Configuration & API
Authoring modes
Logic Authoring runs in one of four modes, chosen per run:
| Mode | What it does |
|---|---|
| Single artifact | Generate one artifact from one plain-language description |
| Multi-artifact suite | Generate a full set from one brief, planned as a dependency graph and built in order |
| Interactive enrichment | Work through the enriched brief conversationally, resolving ungroundable references as questions before anything runs |
| Update | Make a targeted change to an existing artifact, with a reviewed before/after diff |
Bring your own model and provider
Generation is model- and provider-independent, and uses no fine-tuning, so switching the model changes nothing about behaviour or output shape. Choose the provider per project:
- Claude
- OpenAI
- Gemini
- Azure AI Foundry
- your own model deployment
Because the agent uses no fine-tuning, you can switch the generation model and provider with a single setting, with no re-training and no change to how it grounds, validates, or repairs.
Per-project configuration
Logic Authoring is configured per project through structured, versioned settings. You tune the run, not the contract, the grammar and grounding logic are the product-managed contract; you tune what runs against it.
| Setting | What it controls |
|---|---|
| Target project | The project the artifacts are created in and grounded against |
| Model & provider | Which model and provider generate the metadata (see above) |
| Authoring mode | Single artifact, multi-artifact suite, interactive enrichment, or update |
| Self-heal depth | How many generate → validate → repair iterations an artifact may take before it is surfaced for attention |
| Prompt parameters | Output language, a glossary of preferred terms, and a free-text writing addendum |
New artifact types are added over the shared engine as product-managed catalog entries, without a code release to the pipeline, so the set of things you can author grows without changing how you configure it.
Approval and safety
Because Logic Authoring writes to your project, approval is part of the surface, not optional:
- The enriched plan is approved before generation runs.
- Every create and every update is approved before it is written.
- Updates show a before/after diff.
- Name collisions are resolved by reuse or rename, never a silent duplicate or overwrite.
All writes go through Logic Assist (the MCP server) on behalf of the signed-in user, so an artifact is only ever created where that user is permitted to create it, and managed-solution protection still applies.
REST API
The base path is api/authoring. The web application is a client of this API, so every capability is available programmatically. Like the other agents, it authenticates the incoming user and calls downstream services on-behalf-of them, and streams progress over Server-Sent Events.
Authoring
| Method and path | Purpose |
|---|---|
POST /api/authoring/enrich | Enrich and ground a brief; returns the plan to approve |
POST /api/authoring/plan | Plan the dependency graph for a multi-artifact brief |
POST /api/authoring/jobs | Start an authoring job from an approved plan and receive a jobId |
GET /api/authoring/jobs/{jobId}/stream | Subscribe to the generate/validate/repair progress stream (SSE) |
GET /api/authoring/jobs/{jobId} | Get job status |
POST /api/authoring/jobs/{jobId}/approve | Approve a pending create or update so it is written |
Projects and configuration
| Method and path | Purpose |
|---|---|
GET /api/projects | List available projects |
GET /api/authoring/projects/{projectId}/config | Read the effective authoring config plus overrides |
PUT /api/authoring/projects/{projectId}/config | Save a sparse authoring-config override |
All endpoints require authentication and act on behalf of the signed-in user. See the Installation guide for the auth model.