Identity
The governed surface maps requests to an authenticated identity and the directory attributes the selected implementation can reliably use.
Illustrative reference design
Conductor reference architecture
A reviewable model for governed access to approved AI models. It is architecture to adapt and validate, not a deployed or off-the-shelf Graph42 software product.
Reference-design statusAvailable for inspection. Implementation choices remain client-specific.
Architecture diagram
One request path, with controls across it.
- 01
Capture
One governed surface receives the request. Users state the task; model selection follows policy, task fit, and approved choice where required.
- 02
Route
The task is classified and matched against a capability registry using policy, quality, risk, and cost criteria defined by the organization.
- 03
Run
The request reaches an approved provider through the selected tenant controls. Fallback, budget, and availability rules are applied where the chosen implementation supports them.
- 04
Govern
Routing decisions, usage, cost, and the permitted request and response record are captured according to the organization’s privacy, retention, and audit policies.
Cross-cutting governance
- Single sign-on and directory-driven provisioning
- Role-based access by team, role, and model
- Redaction of sensitive data before egress
- A unified audit trail across governed requests
- Cost attribution to a named team, owner, or business purpose
Layer explanations
Where policy becomes an operating control
Routing and policy
Task, capability, risk, quality, and cost criteria inform a permitted route. Approved choice remains available where client policy requires it.
Redaction and egress
Sensitive-data handling occurs before provider egress where supported, with rules and exceptions defined against client data policy.
Provider execution
Modular adapters connect only approved provider tenants and models. Their controls and behavior are assessed rather than assumed equivalent.
Audit and cost
The permitted record of decisions, usage, evidence, and cost is attributed according to privacy, retention, and operating policy.
Assumptions
What the design assumes
- A client can identify an accountable service owner and participating teams
- Identity, data-handling, retention, and procurement constraints can be made explicit
- Provider and model approval remains a client governance decision
- Operating responsibility and exception handling are assigned before production use
Implementation-dependent
What cannot be inferred from the diagram
- Provider-specific control coverage and tenant configuration
- The content permitted in request, response, and audit records
- Redaction patterns, confidence thresholds, and exception paths
- Fallback, budget, availability, and model-selection behavior
- Hosting boundary, residency, observability, and support model
What the assessment adapts
From reference design to a decision
The assessment maps identity and roles, data boundaries, policy and retention, provider strategy, cost ownership, contractual constraints, operating responsibilities, and product fit. It produces an adapted architecture, evaluation record, and explicit recommendation.
What a pilot must prove
Evidence before production consideration
A client-specific pilot must demonstrate the chosen request path with an approved team and constrained model set; exercise agreed identity, policy, redaction, audit, and cost controls; document exceptions; and meet success and exit criteria written before work begins. Passing a pilot does not automatically establish production readiness.
Next decision
Adapt the design to your constraints.
Start with the two-week current-state and architecture assessment, then proceed only when the evidence supports it.