Module 7: Real-World Integration Patterns

7.1 — Integration Patterns

Three approaches, depending on your architecture:

Pattern A: Gateway Proxy

VCP sits between your application and the LLM provider. Every request passes through VCP evaluation before reaching the model. Best for retrofitting VCP onto existing applications without modifying application code.

App → VCP Gateway → LLM Provider
                  ↓
           Audit Trail

Pattern B: Middleware

VCP evaluation is a middleware layer in your application's request pipeline. Best for applications with existing middleware patterns (FastAPI, Express, etc.).

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
from creed_sdk import CreedClient

app = FastAPI()
vcp_client = CreedClient(api_key="crd_live_...")


@app.middleware("http")
async def vcp_middleware(request: Request, call_next):
    if request.method != "POST":
        return await call_next(request)

    body = await request.json()
    decision = await vcp_client.decide(
        tool_name=request.url.path,
        arguments=body,
        constitution_id=get_active_constitution(request),
    )

    if decision.decision == "DENY":
        return JSONResponse(
            status_code=403,
            content={"reasons": decision.reasons, "guidance": decision.guidance},
        )

    request.state.vcp_token = decision.decision_token
    return await call_next(request)

Pattern C: Embedded SDK

VCP calls are made directly in your application logic, giving you full control over when and how evaluation happens. Best for applications that need fine-grained control over what gets evaluated.

7.2 — Multi-Constitution Composition

Real applications often need multiple constitutions simultaneously:

• An organisation-wide code of conduct plus a domain-specific medical constitution
• A user's personal values plus a platform's safety baseline

VCP handles composition by evaluating against multiple constitutions. The evaluation considers all active constitutions and resolves conflicts based on priority and scope:

# Evaluate against the organisation's baseline first, then the medical overlay
baseline_decision = await client.decide(
    tool_name="respond",
    arguments={"message": user_input},
    constitution_id="org_baseline",
)

if baseline_decision.decision == "ALLOW":
    # Now check the domain-specific constitution
    domain_decision = await client.decide(
        tool_name="respond",
        arguments={"message": user_input},
        constitution_id="medical_v2",
    )
    # Use the most restrictive decision
    final_decision = domain_decision
else:
    final_decision = baseline_decision

7.3 — Error Handling and Degraded Operation

What happens when the VCP service is unreachable? Three strategies:

1. Fail closed (recommended for high-stakes)

If VCP is unavailable, deny all actions. Safety over availability.

from creed_sdk import CreedError

try:
    decision = await client.decide(...)
except CreedError:
    # Fail closed: refuse to proceed without VCP evaluation
    logger.critical("VCP unreachable — declining action")
    return deny_response("Value verification unavailable")

2. Fail open with logging

Allow actions but log that VCP evaluation was skipped. Review later.

try:
    decision = await client.decide(...)
except CreedError:
    logger.warning("VCP unreachable — proceeding without evaluation")
    decision = None  # Proceed but log the gap

3. Cached evaluation

Use a recently-cached constitution for local evaluation. Verify freshness when connectivity returns.

7.4 — Performance Considerations

• Decision latency: Typical ~50–200ms per call
• Caching: Constitution content can be cached; individual decisions should not be
• Batching: For bulk operations, evaluate multiple actions in sequence or parallel
• Async: Both SDKs support async operation for non-blocking evaluation — use this in production

VCP is designed to fit your architecture, not the other way around. Choose the pattern that matches your existing stack and risk profile.