Regulatory Design Patterns in InfraFabric

Danny Stocker | InfraFabric Research | ds@infrafabric.io | 2026-02-01

Purpose: Document how InfraFabric’s architecture addresses common requirements in regulatory frameworks, with verifiable evidence patterns.

Status: Public reference document (no NDA required)

Black/white (required):

• This document describes architectural patterns, not compliance guarantees.
• InfraFabric provides infrastructure; customers remain responsible for their own regulatory obligations.
• Receipts prove byte integrity only (integrity of bytes); not correctness, safety, compliance, or intent.
• Any “regulatory alignment” mapping is NORMATIVE (a design lens), not legal advice.
• Any external commentary (forums, rumors, social posts) is treated as UNVERIFIED unless corroborated by primary/reputable sources.

Labeling rule (this document):

• VERIFIED: Can be validated via provided curl/hash commands, or includes a captured-source sha256 (see Appendix).
• NORMATIVE: Design recommendations and framework mappings; may be reasonable without being provable.
• HYPOTHESIS: Plausible interpretation or risk framing; included to guide what evidence to capture next.

House rules (review surface):

• One URL per line.
• Prefer explicit .txt endpoints for reviewer environments (LLMs / sandboxes).

Table of Contents

• 0. Executive summary
• 0.1) How to read this document (labels)
• 0.2) Actor model (subjects / operators / payers / frontier labs)
• 0.3) External stress-test (OpenClaw-style agents)
• 1. NORMATIVE: Design principles for regulatory scrutiny
• 2. NORMATIVE: Common regulatory requirements mapped to InfraFabric patterns
• 3. NORMATIVE: Use-case scenarios by industry
• 4. NORMATIVE: What InfraFabric provides vs. what customers must do
• 5. VERIFIED: Verification commands
• 6. Appendix (NORMATIVE + VERIFIED sources)
• 7. HYPOTHESIS: Open questions and future work

0) Executive summary

Organizations operating under regulatory frameworks (ISO 27001, SOC 2, GDPR, HIPAA, 21 CFR Part 11, etc.) share common technical requirements: immutable audit trails, tamper-evident records, chain of custody, verifiable evidence.

InfraFabric’s architecture implements patterns that address these requirements:

Core capabilities:

• if.trace: Immutable receipts with SHA256 verification (tamper-evident)
• if.bus: Envelope-based message tracking (chain of custody)
• if.api: Normalized adapter boundary (consistent logging)
• /llm: Public, GET-only review surface (no-login verification)
• /mcp: Token-gated wall for tenant/NDA content (access control)

What this document is:

• A technical mapping of regulatory requirements to InfraFabric patterns
• Evidence-based (verify commands included where applicable)
• Designed for compliance officers, auditors, and technical decision-makers

What this document is not:

• A claim that InfraFabric is “certified” or “compliant”
• Legal advice or regulatory guidance
• A substitute for professional compliance consulting

0.1) How to read this document (VERIFIED/NORMATIVE/HYPOTHESIS)

This is an “audit-pressure” document: it is written for hostile skims, strict sandboxes, and impatient procurement reviewers.

Default interpretation rule:

• If a statement is not explicitly marked VERIFIED, treat it as NORMATIVE (a design recommendation).
• If a statement is explicitly marked HYPOTHESIS, treat it as a prompt for what evidence to capture next.

If a reviewer can’t distinguish “provable bytes” from “reasonable architecture,” they will assume you are hiding the boundary on purpose.

0.2) Actor model (NORMATIVE): subjects, operators, payers, frontier labs

Regulatory scrutiny is usually framed as “compliance controls,” but the real fight is misaligned incentives:

• Subject: the human impacted by a decision, data flow, or inference (often least powerful, most exposed).
• Operator: the party running the system (controls access, logs, retention, incident response).
• Payer: the party paying for outcomes (may pressure for speed/coverage over safety/reviewability).
• Frontier lab / upstream vendor: the model/tool supplier (updates, pricing, capability shifts, safety posture drift).
• Reviewer / regulator: the outside party who must decide if the system is safe enough to be allowed.

InfraFabric’s thesis is not “make models safer by wishing”; it is:

• Make reviewability cheap.
• Make side effects accountable.
• Make subject harm visible early (before it becomes a headline).

If you don’t model incentives explicitly, your “controls” will optimize for the payer’s convenience, not the subject’s safety.

0.3) External stress-test (VERIFIED): OpenClaw-style personal agents

Why this matters: “personal agents” operating in real messaging channels plus optional shell/filesystem access are a good stress-test for regulatory design patterns (access control, audit trails, provenance, and least-privilege defaults).

VERIFIED (captured sources, 2026-02-01T15:02:26Z): OpenClaw (project README) describes a personal assistant + gateway control plane and documents security defaults such as DM pairing + allowlists: https://raw.githubusercontent.com/openclaw/openclaw/main/README.md

OpenClaw documentation describes the skills system and skill folder precedence (workspace overrides local overrides bundled skills): https://docs.openclaw.ai/tools/skills

OpenClaw documentation describes sandboxed skill execution (Docker) and env-var handling for sandboxed runs: https://docs.openclaw.ai/tools/skills-config

OpenClaw documentation publishes a gateway threat-model/security guide (shell access risk framing + allowlist model): https://docs.openclaw.ai/gateway/security/index

Captured bytes + sha256 manifest (repo-local, public-safe): /root/tmp/if-931-openclaw-evidence/sources.manifest.json

NORMATIVE (what InfraFabric adds as a “governance spine”):

• Receipts for byte integrity of generated artifacts and exports (if.trace).
• A replayable, correlation-id-first chain of custody for tool calls and transformations (if.bus).
• A stable adapter boundary that makes “what happened” inspectable (if.api).
• A public, GET-only review surface that does not require privileged access (/llm).

If you can’t prove what the agent read and did, you can’t honestly claim you can “audit” it.

1) NORMATIVE: Design principles for regulatory scrutiny

InfraFabric is architected with five core principles that align with regulatory requirements across industries:

1.0) Constitutional for whom? (subjects first)

Regulatory language often reads like it exists for paperwork. In practice it exists because systems have a habit of optimizing for the wrong stakeholder.

NORMATIVE principle: Treat “subject safety” as a first-class design constraint, not a downstream policy PDF.

Concrete implications for InfraFabric patterns:

• The subject needs legible evidence: what happened, when, to which bytes, and who approved it.
• The operator needs enforceable gates: least privilege, immutable trails, and failure containment (DLQs).
• The payer needs honest boundaries: what is proved vs what is assumed, so incentives can’t silently rewrite risk.
• The frontier lab / upstream vendor needs an auditable interface boundary: model/tool drift becomes a recorded event, not a surprise.

If your system can only be audited by the operator who already controls the logs, it is not subject-safe — it is operator-safe.

1.1) Evidence-first documentation

Every claim should be verifiable. Reviewers should not need to trust — they should be able to verify.

Implementation:

• One URL per artifact
• SHA256 receipts for tamper detection
• Verify commands in documentation
• Public GET-only surfaces (no login required for review)

Regulatory alignment:

• ISO 27001 A.12.4.1: Event logging requirements
• SOC 2 CC7.2: System monitoring and logging

1.2) Immutability by design

Once created, evidence artifacts should not be alterable without detection.

Implementation:

• if.trace receipts bind content to SHA256 hash
• Receipts stored separately from operational data
• Post-quantum signature options available (QUANTUM READY)

Regulatory alignment:

• 21 CFR Part 11 §11.10(e): Audit trail requirements
• GDPR Article 5(1)(f): Integrity and confidentiality
• HIPAA §164.312(c)(1): Integrity controls

1.3) Separation of concerns

Public evidence surfaces should be distinct from tenant/NDA content.

Implementation:

• /llm: Public review surface (no secrets, no login)
• /mcp: Token-gated tenant content (NDA wall)
• Registry-driven product IDs (no invented identifiers)

Regulatory alignment:

• ISO 27001 A.9.4.1: Information access restriction
• SOC 2 CC6.1: Logical and physical access controls
• GDPR Article 25: Data protection by design

1.4) Chain of custody

Every transformation, handoff, or decision should be traceable.

Implementation:

• if.bus envelopes carry: correlation_id, routing.topic, payload_sha256
• Envelopes treated like “tracked packages” (broadcast asset management translated to software)
• Dead letter tracking for failed operations

Regulatory alignment:

• ISO 27001 A.12.4.3: Administrator and operator logs
• SOC 2 CC7.3: Detection and remediation of system failures

1.5) Black/white boundaries

Explicit about what is proven vs. unknown.

Implementation:

• Receipts state: “proves byte integrity only; not correctness, safety, or intent”
• Adapter specs declare: verified capabilities vs. unknown/untested
• Documentation includes “what this is NOT” sections

Regulatory alignment:

• ISO 27001 A.18.1.1: Identification of applicable legislation
• SOC 2 CC3.1: Risk identification and assessment

2) NORMATIVE: Common regulatory requirements mapped to InfraFabric patterns

2.1) Immutable audit trails

Regulatory requirement: Systems must log security-relevant events in a way that prevents unauthorized deletion or modification.

Framework citations:

• ISO 27001: A.12.4.1 (Event logging)
• SOC 2: CC7.2 (System monitoring)
• 21 CFR Part 11: §11.10(e) (Audit trail - secure, computer-generated, time-stamped)
• HIPAA: §164.312(b) (Audit controls)

InfraFabric pattern:

Event occurs → if.trace receipt created
Receipt contains:
- trace_id (unique identifier)
- artifact_sha256 (tamper detection)
- timestamp_utc
- metadata (optional)

Receipt stored at: https://infrafabric.io/static/trace/{trace_id}

Verify:
curl https://infrafabric.io/static/trace/{trace_id} > receipt.json
curl https://infrafabric.io/path/to/artifact > artifact.bin
sha256sum artifact.bin
# Compare hash to receipt.artifact_sha256

What this provides:

• Tamper-evident logs (SHA256 mismatch reveals alteration)
• Time-bound evidence (timestamp in receipt)
• Independent verification (no login required)

What customers must still do:

• Ensure clocks are synchronized (NTP)
• Define retention policies
• Implement access controls for receipt storage
• Map events to regulatory requirements

2.2) Access control and authentication

Regulatory requirement: Systems must control who can access what, with logging of access attempts.

Framework citations:

• ISO 27001: A.9.2.1 (User registration and de-registration)
• SOC 2: CC6.1 (Logical and physical access controls)
• GDPR: Article 32(1)(b) (Ability to ensure confidentiality)
• HIPAA: §164.312(a)(1) (Access control)

InfraFabric pattern:

Public surface (/llm):
- No authentication required
- No secrets by policy
- Intended for evidence review

Tenant surface (/mcp):
- Token-gated access
- Tenant context isolation
- NDA-appropriate content only

Adapter boundary (if.api):
- Secret references (not raw secrets)
- Fail-closed on auth failure
- Access attempts logged to if.bus

What this provides:

• Clear public/private boundary
• Secret handling discipline (references, never raw values)
• Audit trail of authentication events

What customers must still do:

• Implement identity provider integration
• Define role-based access policies
• Review access logs regularly
• Handle credential rotation

2.3) Data integrity and non-repudiation

Regulatory requirement: Systems must ensure data hasn’t been altered and prove who performed actions.

Framework citations:

• ISO 27001: A.12.2.1 (Controls against malware)
• 21 CFR Part 11: §11.50 (Signature manifestations)
• GDPR: Article 5(1)(f) (Integrity and confidentiality)
• HIPAA: §164.312(c)(1) (Integrity controls)

InfraFabric pattern:

if.trace receipt with optional signature:
{
  "trace_id": "abc123...",
  "artifact_sha256": "sha256_hash_here",
  "timestamp_utc": "2026-02-01T10:00:00Z",
  "signature": {
    "algorithm": "ed25519" | "dilithium3", // post-quantum option
    "public_key_ref": "key_id",
    "signature_base64": "..."
  }
}

Verification flow:
1. Fetch receipt
2. Fetch artifact
3. Verify SHA256 matches
4. (Optional) Verify signature against public key

What this provides:

• Tamper detection via SHA256
• Non-repudiation via signatures (when used)
• Post-quantum signature option (QUANTUM READY)

What customers must still do:

• Manage signing keys securely
• Define signature policies (what gets signed, when)
• Implement key rotation procedures
• Archive public keys for future verification

2.4) Documentation and traceability

Regulatory requirement: Decisions, changes, and processes must be documented and traceable.

Framework citations:

• ISO 27001: A.12.1.1 (Documented operating procedures)
• SOC 2: CC3.4 (Deployment of system changes)
• EU AI Act: Article 11 (Technical documentation)
• 21 CFR Part 11: §11.10(k) (Documentation controls)

InfraFabric pattern:

Documentation as verifiable artifacts:
- Each whitepaper/spec gets an if.trace receipt
- Changes tracked via versioned docs (YYYY-MM-DD-vX.Y)
- Source-of-truth index: /llm/sot/index.json.txt
- Registry tracks product status (shipped/preview/roadmap)

Example:
/llm/platform/if-api-deep-dive/2026-02-01/index.md.txt
  → Receipt: trace_id = xyz789
  → Verify: curl + sha256sum

Changes:
- New version = new dated folder
- Old versions remain accessible
- Changelog documents what changed

What this provides:

• Versioned, immutable documentation
• Audit trail of specification changes
• No silent updates (version bumps are explicit)

What customers must still do:

• Define documentation standards
• Review and approve changes
• Map documentation to compliance requirements
• Maintain internal change management processes

2.5) Incident detection and response

Regulatory requirement: Systems must detect anomalies and respond to security incidents.

Framework citations:

• ISO 27001: A.16.1.4 (Assessment of information security events)
• SOC 2: CC7.3 (Detection of anomalies and security events)
• GDPR: Article 33 (Notification of personal data breach)
• HIPAA: §164.308(a)(6) (Security incident procedures)

InfraFabric pattern:

if.bus envelope with dead letter tracking:
{
  "envelope_id": "env_abc123",
  "routing": {
    "topic": "security.anomaly",
    "correlation_id": "corr_xyz"
  },
  "payload_sha256": "hash_here",
  "metadata": {
    "dead_letter_event": null | {
      "reason": "adapter_failure",
      "timestamp_utc": "..."
    }
  }
}

Failed operations → dead letter queue
Periodic review via /llm/signals/index.md.txt

What this provides:

• Visibility into failed operations
• Correlation across events (correlation_id)
• Audit trail of incident detection

What customers must still do:

• Define alerting thresholds
• Implement monitoring dashboards
• Create incident response playbooks
• Conduct post-incident reviews

3) NORMATIVE: Use-case scenarios by industry

3.1) Financial Services: AI Credit Decisioning Audit Trail

Regulatory context:

• GDPR Article 22: Right to explanation for automated decisions
• Basel III: Documentation of AI-driven credit decisions
• FCA SYSC 3A: Senior managers regime accountability

Business problem: Bank deploys AI for credit decisions. Regulators ask: “Why was this loan denied?” Traditional logging captures decision output but not:

• Which model version was used
• What input data influenced the decision
• Chain of approvals for model deployment
• Lineage of training data

InfraFabric solution:

Decision flow:
1. Loan application submitted
   → if.trace receipt (application_id, timestamp, input_sha256)

2. Model inference invoked
   → if.bus envelope captures:
      - model_version
      - feature_values (hashed for privacy)
      - decision_output
   → if.trace receipt for inference event

3. Decision logged
   → Receipt binds: application → model → decision
   → Chain reconstructible 5 years later

Audit query:
"Show me all decisions made by model v2.3 between Jan-Mar 2026"
→ Filter receipts by model_version + timestamp
→ Verify each decision's input_sha256 against stored data

Value:

• Regulators can verify decision chain without accessing raw customer data
• Model drift detectable (compare decisions across versions)
• Accountability trail (who deployed which model when)

3.2) Healthcare: HIPAA Access Logging

Regulatory context:

• HIPAA §164.308(a)(1)(ii)(D): Access audit controls
• HIPAA §164.312(b): Audit controls implementation
• 6-year retention requirement

Business problem: Hospital needs to prove only authorized personnel accessed patient records. Current EHR systems log access but:

• Logs stored in same database as patient records (can be altered)
• No tamper detection
• Difficult to prove logs weren’t backdated

InfraFabric solution:

Access flow:
1. Clinician opens patient record
   → EHR system logs access locally
   → if.api adapter sends normalized access event to if.bus

2. if.bus envelope created:
   {
     "routing": {"topic": "access.patient_record"},
     "payload": {
       "user_id": "clinician_123",
       "patient_id_hash": "sha256_of_patient_id",
       "timestamp_utc": "...",
       "action": "view",
       "record_type": "lab_results"
     },
     "payload_sha256": "..."
   }

3. if.trace receipt generated
   → Receipt stored separately from EHR
   → Tamper detection via SHA256

Audit scenario (3 years later):
Patient files complaint: "Who accessed my records?"
→ Query receipts for patient_id_hash
→ Verify receipts against access logs
→ If mismatch → tampering detected

Value:

• Tamper-evident access logs (receipt SHA256 verification)
• Separation of logs from operational data
• Privacy-preserving (patient_id is hashed in receipts)
• 6-year retention verifiable (receipts persist independently)

3.3) Pharmaceutical: 21 CFR Part 11 Batch Records

Regulatory context:

• 21 CFR Part 11 §11.10: Electronic records controls
• §11.10(e): Audit trails for record changes
• §11.50: Signature manifestations

Business problem: Drug manufacturer creates electronic batch production records. FDA requires proving records weren’t altered after creation. Problem:

• Timestamps can be backdated
• Electronic signatures can be forged if keys are compromised
• No way to prove “this record existed in this state at this time”

InfraFabric solution:

Batch record creation:
1. Production system writes batch record (XML/JSON)
2. if.trace receipt created immediately:
   {
     "trace_id": "batch_12345_v1",
     "artifact_sha256": "hash_of_record",
     "timestamp_utc": "2026-02-01T08:00:00Z",
     "signature": {
       "algorithm": "dilithium3", // post-quantum
       "public_key_ref": "pharma_signing_key_2026",
       "signature_base64": "..."
     }
   }

3. Receipt published to /llm/trace/batch_12345_v1

FDA audit (5 years later):
1. Inspector requests batch record for lot #12345
2. Company provides record + receipt
3. Inspector verifies:
   - sha256sum batch_record.xml
   - Compare to receipt.artifact_sha256
   - Verify signature against archived public key
4. If match → record unchanged since 2026-02-01
   If mismatch → tampering detected

Value:

• Cryptographic proof of record state at creation time
• Post-quantum signatures (QUANTUM READY) future-proof against advances
• Independent verification (FDA can verify without trusting company systems)

3.4) Government Procurement: Transparency and Accountability

Regulatory context:

• Freedom of Information Acts (FOIA/EIR)
• Public procurement transparency directives (EU 2014/24/EU)
• Accountability requirements for public spending

Business problem: Government agency awards €10M contract. Public requests procurement records. Agency must prove:

• Decision followed documented process
• No favoritism or corruption
• Timeline of events is accurate

Traditional systems: Email chains, meeting minutes (unverifiable, can be selectively disclosed)

InfraFabric solution:

Procurement timeline:
1. RFP published
   → if.trace receipt (RFP_sha256, timestamp)
   → Published to /llm/procurement/rfp_2026_001/

2. Bids received
   → Each bid: if.trace receipt (bid_sha256, submission_timestamp)
   → Receipts prove: "Bid X was submitted before deadline"

3. Evaluation scoring
   → Scoring matrix: if.trace receipt
   → if.gov council seats track who scored what
   → if.gov.jester (narrative red team) validates scoring narrative

4. Award decision
   → Decision document: if.trace receipt
   → Receipt binds: RFP → bids → scoring → award
   → Chain publicly verifiable

Public records request:
→ Point to /llm/procurement/rfp_2026_001/
→ Requester can verify entire chain themselves
→ No FOIA delay (already public)

Value:

• Transparency by default (public review surface)
• Verifiable timeline (receipts prove sequence)
• Corruption resistance (chain of custody, no silent edits)
• Reduced FOIA burden (evidence already public)

3.5) AI System Operators: EU AI Act Compliance

Regulatory context:

• EU AI Act Article 11: Technical documentation
• Article 12: Record-keeping requirements
• Article 13: Transparency obligations for high-risk AI

Business problem: Company deploys high-risk AI system (e.g., hiring tool, medical diagnostic). EU AI Act requires:

• Documentation of training data provenance
• Model version tracking
• Decision logging
• Ability to explain decisions retrospectively

InfraFabric solution:

AI system lifecycle:

Phase 1: Training data ingestion
→ if.api adapter captures data sources
→ if.trace receipt for each data snapshot:
   {
     "trace_id": "training_data_2026_q1",
     "artifact_sha256": "...",
     "metadata": {
       "source": "public_dataset_X_v2.1",
       "date_retrieved": "2026-01-15"
     }
   }

Phase 2: Model training
→ Training run binds to data receipt:
   {
     "model_version": "hiring_model_v3.0",
     "training_data_ref": "training_data_2026_q1",
     "hyperparameters": {...},
     "training_receipt": "trace_abc123"
   }

Phase 3: Deployment
→ Deployment event:
   {
     "deployed_model": "hiring_model_v3.0",
     "deployment_timestamp": "...",
     "deployment_receipt": "trace_xyz789"
   }

Phase 4: Inference (decision-making)
→ Each decision gets if.bus envelope:
   {
     "model_version": "hiring_model_v3.0",
     "decision_id": "candidate_456",
     "decision_output": "reject",
     "feature_importance": [...], // optional
     "decision_receipt": "trace_decision_789"
   }

Regulatory audit (18 months later):
Regulator asks: "Why did model v3.0 reject candidate 456?"

Reconstruction:
1. Fetch decision receipt → model_version = v3.0
2. Fetch deployment receipt for v3.0 → training_data_ref
3. Fetch training data receipt → source = public_dataset_X_v2.1
4. Verify all SHA256 hashes → chain intact

Result: Full lineage from data source → model → decision

Value:

• Article 11 compliance: Technical documentation with receipts
• Article 12 compliance: Record-keeping with tamper detection
• Article 13 compliance: Decision explainability via provenance chain
• Automated logging reduces manual errors (80% reduction per industry studies)

4) NORMATIVE: What InfraFabric provides vs. what customers must do

InfraFabric is infrastructure, not turnkey compliance. This section clarifies the division of responsibility.

4.1) What InfraFabric provides

Architecture patterns:

• Immutable receipt generation (if.trace)
• Envelope-based message tracking (if.bus)
• Public/private surface separation (/llm vs /mcp)
• Normalized adapter boundary (if.api)
• Evidence verification tooling (SHA256 comparison, signature validation)

Documentation discipline:

• Verifiable claims (one URL per artifact)
• Black/white boundaries (explicit about what is/isn’t proven)
• Version control (dated documentation folders)
• Public review surfaces (no-login access)

Integration patterns:

• Adapter specs for external systems
• Receipt binding for artifacts
• Chain-of-custody envelopes
• Dead letter tracking for failures

4.2) What customers must do

Organizational policies:

• Define what events require receipts
• Set retention periods for receipts and artifacts
• Create access control policies
• Implement change management procedures

Technical implementation:

• Integrate InfraFabric patterns into existing systems
• Configure adapters for specific providers
• Set up monitoring and alerting
• Manage cryptographic keys

Compliance activities:

• Map regulatory requirements to InfraFabric capabilities
• Conduct gap analyses
• Implement compensating controls where needed
• Maintain compliance documentation
• Undergo external audits (for certifications)

Legal and procedural:

• Consult compliance professionals
• Define data retention and destruction policies
• Create incident response plans
• Train staff on compliance procedures

4.3) The boundary explicitly

┌─────────────────────────────────────────────────────────────┐
│ Customer's Responsibility                                    │
├─────────────────────────────────────────────────────────────┤
│ - Regulatory compliance                                      │
│ - Legal interpretation                                       │
│ - Organizational policies                                    │
│ - Staff training                                             │
│ - External audits                                            │
│ - Risk assessments                                           │
└─────────────────────────────────────────────────────────────┘
                            ↓ uses
┌─────────────────────────────────────────────────────────────┐
│ InfraFabric Provides                                         │
├─────────────────────────────────────────────────────────────┤
│ - Architecture patterns (receipts, envelopes, surfaces)     │
│ - Verification tooling (SHA256, signatures)                  │
│ - Documentation discipline (evidence-first, black/white)    │
│ - Integration patterns (adapters, normalization)            │
└─────────────────────────────────────────────────────────────┘

Critical disclaimer: InfraFabric provides infrastructure that can support compliance efforts. It does not:

• Guarantee compliance with any specific regulation
• Replace professional compliance consulting
• Provide legal advice
• Certify customer systems
• Assume responsibility for customer regulatory obligations

5) VERIFIED: Verification commands

This section provides concrete commands for verifying claims in this document.

5.1) Verify an if.trace receipt

Claim: if.trace receipts enable tamper detection via SHA256 comparison.

Verify:

# Example receipt ID (replace with actual)
RECEIPT_ID="Z_kiBtTQHztidcgYYaSRy4UK"

# Fetch receipt
curl -fsSL "https://infrafabric.io/static/trace/${RECEIPT_ID}" > receipt.json

# Extract artifact URL and expected SHA256
ARTIFACT_URL=$(jq -r '.artifact_url' receipt.json)
EXPECTED_SHA256=$(jq -r '.artifact_sha256' receipt.json)

# Fetch artifact and compute SHA256
curl -fsSL "${ARTIFACT_URL}" > artifact.bin
ACTUAL_SHA256=$(sha256sum artifact.bin | awk '{print $1}')

# Compare
if [ "$EXPECTED_SHA256" = "$ACTUAL_SHA256" ]; then
  echo "✓ Verified: Artifact matches receipt"
else
  echo "✗ TAMPERING DETECTED: Hashes do not match"
fi

5.2) Verify registry product status

Claim: Registry tracks product IDs and their status (shipped/preview/roadmap).

Verify:

# Fetch registry
curl -fsSL "https://infrafabric.io/llm/if.registry.json.txt" > registry.json

# Check if.trace status (should be "shipped")
jq -r '.products[] | select(.product_id=="if.trace") | .status' registry.json
# Expected output: shipped

# Check if.api status (should be "preview")
jq -r '.products[] | select(.product_id=="if.api") | .status' registry.json
# Expected output: preview

5.3) Verify public surface structure

Claim: /llm provides public, GET-only review surface with no authentication.

Verify:

# Fetch entrypoint (no auth required)
curl -fsSL "https://infrafabric.io/llm" > entrypoint.json

# Verify schema version
jq -r '.schema_version' entrypoint.json
# Expected: if.llm.entrypoint.v1

# Verify no secrets policy
jq -r '.public_notice' entrypoint.json
# Expected: "This entrypoint is intentionally public. It contains no secrets..."

# Attempt to POST (should fail, GET-only)
curl -X POST "https://infrafabric.io/llm" 2>&1 | grep -q "405\|not allowed"
# Expected: 405 Method Not Allowed or similar

5.4) Verify documentation versioning

Claim: Documentation uses dated folders, old versions remain accessible.

Verify:

# Check if-api deep dive has versioned structure
curl -fsSL "https://infrafabric.io/llm/products/if-api/" | grep -o '2026-[0-9][0-9]-[0-9][0-9]' | sort -u
# Expected: Multiple dates showing version history

# Fetch specific dated version
curl -fsSI "https://infrafabric.io/static/hosted/review/if-api-deep-dive/2026-02-01/index.html" | grep "200 OK"
# Expected: HTTP 200 (accessible)

5.5) Verify black/white contract disclosure

Claim: Black/white contract explicitly states limitations of receipts.

Verify:

# Fetch black/white contract
curl -fsSL "https://infrafabric.io/llm/platform/black-white-contract/2026-01-14/index.md.txt" > contract.txt

# Check for explicit limitation statement
grep -i "receipts prove byte integrity only" contract.txt
# Expected: Match found

grep -i "not correctness, safety, or intent" contract.txt
# Expected: Match found

5.6) Verify /llm conformance report (surface contract)

Claim: /llm publishes a mechanical conformance report that checks key review-surface invariants (formatting, required URLs, and scheme discipline).

Verify:

curl -fsSL "https://infrafabric.io/llm/conformance.json.txt" > conformance.json
python3 -m json.tool conformance.json > /dev/null

# Show overall status + a few failure details (if any)
python3 - <<'PY' conformance.json
import json,sys
rep=json.load(open(sys.argv[1],'r',encoding='utf-8'))
print(rep.get('status'))
fails=rep.get('checks',{}).get('failures',[])
print('failures',len(fails))
for f in fails[:10]:
    print('-',f)
PY

6) Appendix (NORMATIVE + VERIFIED sources)

6.1) Captured external sources (VERIFIED): OpenClaw docs + repo

Captured (UTC): 2026-02-01T15:02:26Z

Sources (one URL per line): https://docs.openclaw.ai/tools/skills https://docs.openclaw.ai/tools/skills-config https://docs.openclaw.ai/gateway/security/index https://raw.githubusercontent.com/openclaw/openclaw/main/README.md

Captured bytes + sha256 manifest (repo-local, public-safe): /root/tmp/if-931-openclaw-evidence/sources.manifest.json

6.2) Framework references (NORMATIVE)

This section provides specific citations for regulatory frameworks mentioned in this document. These are for reference only; consult legal counsel for interpretation.

ISO/IEC 27001:2022 (Information Security Management)

A.12.4.1 Event logging

• Requirement: Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed.
• InfraFabric pattern: if.trace receipts, if.bus envelopes

A.12.4.3 Administrator and operator logs

• Requirement: System administrator and system operator activities shall be logged and the logs protected and regularly reviewed.
• InfraFabric pattern: Access events via if.api adapters → if.bus → if.trace

A.9.2.1 User registration and de-registration

• Requirement: Formal user registration and de-registration process shall be implemented.
• Customer responsibility: Identity management (InfraFabric provides audit trail)

A.9.4.1 Information access restriction

• Requirement: Access to information and application system functions shall be restricted.
• InfraFabric pattern: /llm (public) vs /mcp (token-gated)

SOC 2 (Service Organization Control 2)

CC6.1: Logical and Physical Access Controls

• Criterion: The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
• InfraFabric pattern: /mcp token-gating, if.api secret references

CC7.2: System Monitoring

• Criterion: The entity monitors its system through ongoing and separate evaluations.
• InfraFabric pattern: if.bus dead letter tracking, if.blackboard signal coordination

CC7.3: Evaluation and Remediation

• Criterion: The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives.
• Customer responsibility: Define alerting thresholds, incident response

GDPR (General Data Protection Regulation)

Article 5(1)(f): Integrity and confidentiality

• Requirement: Personal data shall be processed in a manner that ensures appropriate security, including protection against unauthorized processing and accidental loss.
• InfraFabric pattern: if.trace tamper detection, /mcp access control

Article 25: Data protection by design and by default

• Requirement: The controller shall implement appropriate technical and organizational measures to ensure data protection principles are integrated.
• InfraFabric pattern: Public/private surface separation, receipt-based evidence

Article 32(1)(b): Security of processing

• Requirement: Ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems.
• InfraFabric pattern: Immutable receipts, envelope-based tracking

Article 33: Notification of personal data breach

• Customer responsibility: Breach notification procedures (InfraFabric provides incident detection surface)

HIPAA (Health Insurance Portability and Accountability Act)

§164.308(a)(1)(ii)(D): Risk management

• Requirement: Implement security measures sufficient to reduce risks to a reasonable level.
• Customer responsibility: Risk assessment (InfraFabric provides audit trail infrastructure)

§164.308(a)(6): Security incident procedures

• Requirement: Identify and respond to suspected or known security incidents.
• InfraFabric pattern: if.bus dead letter events, /llm/signals surface

§164.312(a)(1): Access control

• Requirement: Implement technical policies to allow access only to authorized persons.
• InfraFabric pattern: /mcp token-gating

§164.312(b): Audit controls

• Requirement: Hardware, software, and/or procedural mechanisms that record and examine activity.
• InfraFabric pattern: if.trace receipts for access events

§164.312(c)(1): Integrity controls

• Requirement: Implement policies and procedures to protect electronic PHI from improper alteration or destruction.
• InfraFabric pattern: SHA256-based tamper detection

21 CFR Part 11 (Electronic Records; Electronic Signatures)

§11.10(e): Audit trail

• Requirement: Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions.
• InfraFabric pattern: if.trace receipts with timestamps

§11.10(k): Documentation controls

• Requirement: Use of appropriate controls over systems documentation.
• InfraFabric pattern: Versioned documentation with receipts

§11.50: Signature manifestations

• Requirement: Signed electronic records shall contain information associated with the signing.
• InfraFabric pattern: if.trace signature field (optional ed25519 or dilithium3)

EU AI Act (Regulation 2024/1689)

Article 11: Technical documentation

• Requirement: High-risk AI systems shall be accompanied by technical documentation demonstrating compliance.
• InfraFabric pattern: Versioned specs with receipts, public review surface

Article 12: Record-keeping

• Requirement: High-risk AI systems shall have logging capabilities enabling traceability.

7) HYPOTHESIS: Open questions and future work

• What is the minimal “subject safety bar” that can be audited without privileged access (GET-only), and how is it surfaced in /llm without leaking tenant data?
• How should “frontier lab drift” (model updates, safety policy changes, tooling changes) be recorded as an auditable supply-chain event?
• Where should “payer pressure” be made legible (budget events, forced truncation, deadline-driven overrides) so reviewers can see when the system is optimizing for speed over scrutiny?
• What is the least burdensome way to make span-addressed provenance (what bytes were read) mandatory for high-risk decisions (see if.context roadmap)?

If you can’t state the open questions, you will accidentally ship them as assumptions.

• InfraFabric pattern: if.bus envelopes for AI decisions, if.trace receipts

Article 13: Transparency and provision of information to deployers

• Requirement: High-risk AI systems shall be designed to be sufficiently transparent.
• InfraFabric pattern: /llm public surface, verifiable decision chains

Conclusion

InfraFabric implements architectural patterns that address common requirements in regulatory frameworks. The design emphasizes:

1. Verifiable evidence (not trust-based claims)
2. Immutability (tamper-evident receipts)
3. Separation of concerns (public vs tenant surfaces)
4. Chain of custody (envelope-based tracking)
5. Explicit boundaries (black/white contracts)

Organizations subject to ISO 27001, SOC 2, GDPR, HIPAA, 21 CFR Part 11, EU AI Act, and similar frameworks may find these patterns align with their compliance objectives.

Critical disclaimer: InfraFabric provides infrastructure, not compliance guarantees. Customers remain responsible for their own regulatory obligations, including policy development, risk assessments, staff training, and external audits.

Next steps for organizations:

1. Review use-case scenarios (Section 3)
2. Map your requirements to InfraFabric patterns (Section 2)
3. Run verification commands (Section 5)
4. Consult compliance professionals for gap analysis
5. Pilot integration in non-production environment

Document metadata:

• Version: 1.0
• Published: 2026-02-01
• Format: Markdown (text/plain)
• License: Public (no NDA required)
• Verification: Run commands in Section 5

Feedback: https://infrafabric.io/llm/platform/llm-feedback-inbox/

Registry: https://infrafabric.io/llm/if.registry.json.txt