Document Pipelines for Manufacturing Compliance on Azure

What the Standards Actually Require

The quality-management standards converge on five operational requirements for controlled documents:

• Approval before issue. Every document must have a documented approval record before it becomes effective.
• Revision control. Changes are tracked, reviewed, and approved. Superseded revisions are identifiable as such.
• Distribution control. Current versions are available where needed; obsolete versions are either removed or flagged to prevent unintended use.
• Retention. Records are preserved for the period specified by the standard or by the organisation, often 10–30 years for safety-critical documentation.
• Auditability. Who did what, when, with which document, under which approval — reconstructible for any auditor's question.

Search is not in the standards. What the standards care about is the pipeline that produced the searchable artifact: the approvals, the revision history, the distribution records. Azure AI Search indexes the resulting documents; the pipeline behind it provides the compliance scaffolding.

The Reference Architecture

A compliance-aware document pipeline on Azure has six stages:

1. Ingestion landing zone. Azure Blob Storage container, immutable (WORM) lock for retention, with per-document metadata including originator, approval references, and revision identifier.
2. Approval workflow. Azure Logic Apps or Durable Functions orchestrating the review and sign-off chain. Approvers interact via Microsoft Teams adaptive cards or a custom web UI. Decisions are written to a signed audit log.
3. Promotion to effective storage. Once approved, a deterministic step moves the document from the approval zone to the effective-revisions container and updates the document registry.
4. Indexer ingestion. Azure AI Search indexer picks up documents from the effective container, runs the skillset, and populates the index with full metadata.
5. Search and retrieval. Users query via the application; retrieval is filtered to show only currently-effective revisions unless the user explicitly searches history.
6. Archive and retention. Superseded revisions move to an archive container with a retention policy matching regulatory requirements. Nothing is deleted; everything is discoverable for audit.

The Metadata Schema That Supports Audits

The metadata attached to each document in Blob Storage and mirrored in the search index is the primary audit surface. Eight fields matter:

// Controlled-document metadata on Blob Storage
{
  "documentId":       "QP-4.2.3-009",
  "revision":         "B",
  "title":            "Receiving Inspection Procedure for Cast Aluminum Parts",
  "effectiveDate":    "2026-02-15T00:00:00Z",
  "supersedesRev":    "A",
  "approver":         "user@corp.example",
  "approvalId":       "APPROVAL-4721",
  "retentionClass":   "iatf-10yr",
  "sourceSystem":     "plm.intranet",
  "sha256":           "9f2c...",
  "immutabilityPolicyExpiry": "2036-02-15T00:00:00Z"
}

The sha256 hash is the keystone. It is calculated at ingestion, stored alongside the document, and logged in the approval record. When an auditor asks "is this document the one that was approved in 2026?" the answer is "yes, hash matches." Any modification breaks the hash and surfaces as a tamper indicator.

The Index Schema

// Azure AI Search schema fragment for controlled documents
{
  "fields": [
    { "name": "id",              "type": "Edm.String",    "key": true },
    { "name": "documentId",      "type": "Edm.String",    "filterable": true, "facetable": true },
    { "name": "revision",        "type": "Edm.String",    "filterable": true },
    { "name": "title",           "type": "Edm.String",    "searchable": true, "filterable": true },
    { "name": "content",         "type": "Edm.String",    "searchable": true },
    { "name": "contentVector",   "type": "Collection(Edm.Single)",
      "searchable": true, "dimensions": 1536, "vectorSearchProfile": "hnsw-cosine" },
    { "name": "docType",         "type": "Edm.String",    "filterable": true, "facetable": true },
    { "name": "process",         "type": "Edm.String",    "filterable": true, "facetable": true },
    { "name": "effectiveDate",   "type": "Edm.DateTimeOffset", "filterable": true, "sortable": true },
    { "name": "status",          "type": "Edm.String",    "filterable": true, "facetable": true },
    { "name": "approver",        "type": "Edm.String",    "retrievable": true },
    { "name": "approvalId",      "type": "Edm.String",    "retrievable": true },
    { "name": "sha256",          "type": "Edm.String",    "retrievable": true }
  ]
}

The status field carries values like effective, superseded, draft, withdrawn. Default query filter: status eq 'effective'. History queries remove that filter explicitly.

Immutability and Retention

Azure Blob Storage's immutability policy (WORM) is the regulatory-grade retention mechanism. Once applied to a container, blobs cannot be modified or deleted for the policy duration. Time-based policies match retention clauses directly: immutability: { policyMode: "unlocked", retentionPeriodInDays: 3650 } for a 10-year retention, transitioned to locked once the organisation formally commits to the retention period.

Superseded revisions stay in the effective container with status flipped to superseded, or migrate to an archive container depending on the organisation's preference. Either way, they remain queryable by auditors. The immutability policy ensures their content is unchanged from approval.

The Approval Workflow Shape

For a new document revision, the workflow is deterministic:

// Durable Functions orchestration (TypeScript)
export async function* documentApproval(ctx: OrchestrationContext, input: Submission) {
  const hashed = yield ctx.callActivity('hashAndStage', input);

  const reviewResult = yield ctx.callActivity('requestReview', {
    documentId: hashed.documentId, reviewers: input.reviewers,
  });
  if (!reviewResult.approved) {
    yield ctx.callActivity('notifyRejected', { reason: reviewResult.reason });
    return;
  }

  const signedApproval = yield ctx.callActivity('issueApproval', {
    documentId: hashed.documentId, sha256: hashed.sha256,
    approvers: reviewResult.approvers, timestamp: ctx.currentUtcDateTime,
  });

  yield ctx.callActivity('promoteToEffective', {
    documentId: hashed.documentId, revision: input.revision,
    supersedesRev: input.supersedesRev, approvalId: signedApproval.id,
  });

  yield ctx.callActivity('markPredecessorSuperseded', {
    documentId: hashed.documentId, supersededRev: input.supersedesRev,
  });

  yield ctx.callActivity('triggerIndexerRun', { indexerName: 'mfg-qms-indexer' });
}

The Audit Log

Every state change writes an entry to an append-only audit log, typically Azure Storage append blobs or a dedicated Cosmos DB container with immutability. The log captures: actor, action, target document, sha256, timestamp, reason. Querying the log reconstructs "what happened with document QP-4.2.3-009 between 2024 and 2026" in seconds.

The log is cross-referenced with the Azure Entra sign-in logs for actor verification. Azure Monitor retains Entra sign-in logs for 30–90 days by default; for a 10-year compliance horizon, the logs must be exported to long-term storage (Log Analytics with retention extended, or a dedicated Storage Account).

Access Control

Access to controlled documents is scoped via Azure Entra groups and Azure AI Search's security trimming. A trimming field on each index entry lists the groups permitted to see it; the application passes the user's group memberships as a filter. Access reviews run quarterly. Revoking access revokes retrieval.

What Auditors Actually Ask

• Show me the approval record for revision B of QP-4.2.3-009. → Audit log query on approvalId.
• Prove this is the document that was approved. → Hash comparison against the immutable record.
• Who had access to this document between these two dates? → Entra group membership history plus security trimming field.
• When did revision A become superseded? → Audit log state-change entry with timestamp.
• Show me all documents that reference the recalled supplier PN-4477. → Search query filter on partNumbers.

Common Pitfalls

• Immutability applied too late. Setting WORM only on the archive container leaves the effective container mutable. Auditors want immutability from approval forward.
• Indexer runs on every blob upload. If the pipeline uploads both draft and approved revisions to the same container, indexer may ingest drafts. Keep drafts in a separate container excluded from the indexer scope.
• Logs over-retained at expense of query speed. Hot logs at Azure Monitor retention limits are expensive. Tier to cool storage for long-term archival; keep only the last 12 months queryable in Log Analytics.
• Security trimming not consistent with Entra changes. When a user leaves, their group membership disappears but old index entries may still reference them as approver. That is correct (historical record). What must stop is their access; that comes from the security-trimming field plus Entra group membership at query time.

Operational Cost Ballpark

For a mid-sized manufacturer with 500,000 controlled documents and 50–200 approvals per month: Azure AI Search S2 (~2,800 USD/month), Storage with immutability (~400 USD/month for 1 TB hot tier), Logic Apps/Durable Functions (~200 USD/month), Log Analytics retention (~300 USD/month). Total around 3,700 USD/month for the pipeline layer, excluding Azure OpenAI embedding costs which scale with corpus size.

A Final Word on Standards

ISO 9001, IATF 16949, AS9100, and ISO 13485 are implementation-agnostic. They do not mandate technology choices. Azure AI Search, Blob Storage with immutability, Durable Functions, and Entra-backed access are one set of coherent building blocks. Auditors accept the result when the pipeline is documented, controlled, and traceable. The platform choice matters far less than whether the pipeline behaves deterministically and keeps the audit trail intact. Get that right and the certification review is a short conversation.