| title | Procurement Contract IQ |
|---|---|
| description | Governance and implementation boundary for a synthetic procurement contract review proof of concept |
| ms.date | 2026-07-30 |
| ms.topic | overview |
Note
Why reinvent the wheel? Microsoft ships a first-party Word: Legal Agent in Frontier that generates redlines and reviews counterparty changes directly in Word (see the walkthrough video on that page). This proof of concept explores the upstream governance, evidence, and audit boundary rather than duplicating that agent's authoring experience.
Procurement Contract IQ is a proof of concept for evidence-backed procurement contract review. The planned experience extracts contract structure, retrieves applicable policy evidence, routes clauses to deterministic specialist review passes, and presents proposed redlines for an authorized human decision.
The application is a decision-support tool. It does not approve contracts, establish a customer position, or replace procurement, privacy, security, or legal review.
One ASP.NET Core modular monolith serves the compiled React application and owns authentication, authorization, review state, policy filtering, model routing, schema validation, and export decisions. Azure clients remain behind feature-specific interfaces so local development and deterministic tests do not require Azure access.
flowchart LR
reviewer[Authenticated reviewer]
subgraph app[Azure Container Apps]
web[React application]
api[ASP.NET Core modular monolith]
decision[Human decision boundary]
web --> api
api --> decision
end
subgraph private[Private Azure service boundary]
blob[Blob Storage<br/>source, review, and export]
doc[Document Intelligence<br/>layout extraction]
search[Azure AI Search<br/>authorized policy evidence]
foundry[Microsoft Foundry<br/>bounded specialist inference]
vault[Key Vault]
end
monitor[Application Insights<br/>content-free telemetry]
reviewer -->|HTTPS and Microsoft Entra ID| web
api -->|Managed identity| blob
api -->|Managed identity| doc
api -->|Filtered retrieval| search
api -->|Clause and bounded evidence| foundry
api -->|Managed identity| vault
api -->|Redacted OpenTelemetry| monitor
decision -->|Approved state only| blob
foundry -.->|Proposal only| api
Contract and policy content is untrusted input. It cannot select identities, authorization filters, tools, workflow transitions, or approval decisions. Source anchors and hashes remain stable throughout extraction, retrieval, review, decision, evaluation, and export. Missing authority, anchors, citations, schema fields, jurisdiction, or policy versions fail closed.
Pull request validation runs deterministic checks without cloud credentials.
After validation reaches main, the deployment workflow builds one immutable
container image, provisions Azure resources with Bicep, configures the private
runner, performs smoke checks, and restores the resource lock. A separately
dispatched protected evaluation first repeats offline gates, then routes the
grounded baseline through the VNet-connected runner because Foundry public
network access is disabled.
sequenceDiagram
actor Contributor
participant GitHub as GitHub Actions
participant Azure as Azure deployment identity
participant IaC as Bicep deployment
participant Runner as VNet self-hosted runner
participant Foundry as Private Foundry endpoint
participant Evidence as Artifacts and GitHub wiki
Contributor->>GitHub: Open or update pull request
GitHub->>GitHub: Build, test, lint, scan, and run offline evaluations
GitHub-->>Contributor: Block merge on a failed gate
Contributor->>GitHub: Merge validated commit to main
GitHub->>Azure: Exchange OIDC token
GitHub->>GitHub: Build and push immutable container image
GitHub->>IaC: What-if and deploy tagged resources
IaC->>Runner: Bootstrap tools and register repository runner
GitHub->>Runner: Verify online state and required labels
GitHub->>Azure: Smoke test deployment and restore lock
Contributor->>GitHub: Dispatch protected grounded evaluation
GitHub->>GitHub: Run deterministic offline gate
GitHub->>Runner: Schedule foundry-private job
Runner->>Azure: Exchange protected-environment OIDC token
Runner->>Foundry: Verify private DNS and TCP, then evaluate
Foundry-->>Runner: Groundedness, retrieval, and relevance results
Runner->>Runner: Enforce fail-closed thresholds and sanitize output
Runner->>Evidence: Publish artifact, job summary, and trend history
GitHub-->>Contributor: Report protected gate result
The cloud evaluation publishes metrics and status only. Contract text, policy text, prompts, responses, access tokens, and personal data are excluded from logs, workflow summaries, artifacts, and wiki history.
Repository content, tests, demonstrations, and evaluation datasets must use clearly fictional synthetic data. Do not commit or process real customer contracts, policies, employee information, supplier information, credentials, production telemetry, or other customer data unless repository owners and the applicable customer privacy, security, procurement, and legal roles record explicit authorization and the architecture is updated for that classification.
Synthetic documents must not reproduce confidential clauses or be presented as customer-approved policy. Generated names, organizations, account identifiers, addresses, and signatures must be fictional and traceable to a synthetic-data manifest.
Do not add customer logos, trade names used as visual branding, employee names, likenesses, meeting screenshots, internal file names, or other customer assets without written customer branding and privacy approval. Sanitized product visuals must be created from approved architecture descriptions, not copied or derived from internal screenshots.
Two internal meeting screenshots were removed from the working tree during the governance phase. Their presence in Git history remains a publication blocker. Only a repository owner may authorize and coordinate a history rewrite. Public or customer-facing exposure also remains blocked until the customer branding owner records the permitted use of customer names and marks.
The implementation defaults and unresolved approval gates are recorded in:
- Architecture and compliance decision
- Framework and search reassessment decision
- Demo readiness and rehearsal
- Security data flow
- Success metrics
- Synthetic demo asset rules
- Document export limitations
- Figure description limitations
- Word redline round-trip test procedure
These records authorize implementation against synthetic data only. They do not authorize a customer-facing deployment or the processing of customer data.