Inscripta sits between AI systems and business execution. Companies call the API before prompts, model outputs, or proposed actions reach production systems; the runtime applies tenant constraints, policy, routing, audit, and review gates.
POST /api/v1/gateway/evaluate { "app_id": "company-workflow", "input": "approve supplier change ECN-2847", "context": { "domain": "manufacturing", "action": "change_control.approve" } } returns { "decision": "requires_review", "risk_score": 72, "constraint_refs": ["active-policy-v4"], "audit_ref": "aud_8f41..." }
The dashboard is the control plane. The product surface is the middleware API: a headless runtime that lets company systems evaluate prompts, proposed actions, model output, and domain-specific constraints before execution.
Chatbot, agent workflow, internal tool, or business process sends the request.
Gateway and tenant-scoped APIs normalize and evaluate the proposal.
Active prompt versions, constraints, policies, and routing rules are applied.
Low-risk actions can proceed; risky or ambiguous actions enter review.
Runtime decisions and configuration references are recorded for later review.
Inscripta is organized as a runtime, a security front door, and a converter that makes domain configuration easier to create, review, version, and activate.
The security gateway is the front door for unsafe prompt and request patterns. It supports company API keys, evaluator flows, audit logs, review queues, reports, and LLM provider selection.
The domain runtime is the generalized middleware layer. Domain behavior is configured by tenant policy, prompt versions, constraint sets, routing rules, and human approval controls.
Expert teams can configure Inscripta manually. The converter adds convenience: it helps transform regulations, operating procedures, and business rules into obligations, constraints, and bundles.
The public website should lead with API surfaces because that is where enterprise systems integrate: gateway evaluation, tenant configuration, review decisions, audit evidence, and converter workflows.
Company apps submit prompts or proposed actions before sending them to an LLM or business system.
Teams define active rules, prompt versions, provider choices, routing profiles, and review thresholds.
Risky proposals are decided with explicit approval or rejection and mandatory justification.
Audit records and chain verification APIs support traceability of runtime decisions and configuration.
External business or legal material can be registered, processed, and tracked through async extraction.
Approved converter output can become versioned runtime bundles used by sandbox and law-converter flows.
The middleware does not need manufacturing, defense, healthcare, or legal behavior hardcoded into the application. Those behaviors are represented through tenant configuration and activated artifacts.
Manual configuration works for expert teams. The converter helps transform business rules, regulations, or operating procedures into reviewable obligations, synthesized constraints, and versioned runtime bundles. It is a governed workflow, not an autonomous agent.
Register external law, policy, procedure, or domain source material for tenant-scoped processing.
Normalize candidate requirements into reviewable obligations with provenance and confidence context.
Approve, edit, or reject extracted obligations before they become runtime material.
Generate constraint artifacts from approved obligations so the runtime can evaluate them consistently.
Version bundles and activate the selected domain artifact for the tenant runtime.
These examples describe where the architecture can be configured. The current code supports the configuration model and converter flow; domain readiness depends on the reviewed constraints, prompts, and activated artifacts for each customer.
ECN and change-control workflows, production actions, operational thresholds, and approval paths.
Readiness checks, approval chains, operational constraints, and traceability for sensitive workflows.
Role survey, clause retrieval, analysis, review, training, reporting, and converter artifact flows.
Tenant-specific policies, constraints, provider routing, review rules, and audit requirements.
The dashboard is useful, but it should be framed correctly: operators use it to configure, review, and inspect the middleware. It is not the main integration surface.
Start with one workflow: a chatbot request path, an agent action, or a regulated business process. Inscripta can be evaluated as a headless API layer before expanding into broader domain governance.