Field	Value
RFC ID	004
Title	ROSIE API Interface: Standard Contract for System of Record Interoperability
Version	1.1.0
Status	Draft
Focus	API contracts, REST/gRPC, authentication, webhooks

---

1. Scope

This RFC defines the RESTful API contract that any System of Record (SoR) must implement to support the ROSIE Engine. This prevents vendor lock-in and enables cross-platform compliance synchronization.

1.1 Purpose

ROSIE does not prescribe a specific SoR implementation. This RFC defines the interface contract that any SoR must fulfill. Compliant SoRs may include:

• Commercial QMS platforms (with adapter/plugin)
• PLM systems (with API gateway)
• Custom-built approval applications
• Regulatory SaaS products

1.2 What the SoR Provides

The SoR handles functionality outside ROSIE’s boundary:

Capability	Description
User management	Authentication, roles, permissions
Approval workflows	Configurable approval chains, delegation
Electronic signatures	21 CFR Part 11 compliant capture
Audit trail	Immutable, timestamped records
Retention	Long-term storage per regulations

1.3 What This RFC Defines

This RFC specifies only the API endpoints the ROSIE Engine calls. How the SoR implements these endpoints internally is outside scope.

---

2. Core Endpoints

2.1 POST /v1/sync/manifest

Submits the extracted repository state to the SoR.

Request:

{
  "commit_sha": "abc123def456",
  "manifest_hash": "sha256:...",
  "product": {
    "name": "LabData-Processor-Core",
    "code": "LDPC",
    "version": "2.1.0"
  },
  "nodes": [
    {
      "id": "LDPC-URS-101",
      "type": "requirement",
      "content_hash": "sha256:..."
    }
  ]
}

Response:

{
  "sync_id": "uuid",
  "status": "accepted",
  "drift_detected": false,
  "pending_approvals": ["LDPC-DS-001"]
}

2.2 GET /v1/release/readiness/{sha}

Checks if a specific commit is ready for deployment.

Response (ready):

{
  "is_ready": true,
  "commit_sha": "abc123def456",
  "manifest_hash": "sha256:...",
  "pending_signatures": [],
  "release_token": "eyJhbGciOiJSUzI1NiIs..."
}

Response (not ready):

{
  "is_ready": false,
  "blockers": [
    "Missing approval for LDPC-DS-001",
    "Hash mismatch for LDPC-URS-101"
  ]
}

2.3 POST /v1/evidence/upload

Submits gxp-execution.json (defined in RFC-003) to the SoR.

---

3. Security and Authentication

3.1 Transport Security (MUST)

All API communication must use TLS 1.2 or higher.

3.2 Authentication (MUST)

Method	Header	Description
mTLS	Client certificate	Mutual TLS with engine certificate
OAuth2	Authorization: Bearer <token>	Bearer token from OAuth2 flow
API Key	X-API-Key: <key>	Static API key (development only)

3.3 Non-Repudiation (MUST)

Every request must include an X-ROSIE-Signature header, which is a hash of the payload signed by the engine’s private key:

X-ROSIE-Signature: sha256=<base64-encoded-signature>

---

4. Error Responses

All error responses follow a standard format:

{
  "error": {
    "code": "HASH_MISMATCH",
    "message": "The manifest hash does not match the stored value",
    "details": {
      "expected": "sha256:abc...",
      "received": "sha256:def..."
    }
  }
}

4.1 Standard Error Codes

Code	HTTP Status	Description
UNAUTHORIZED	401	Invalid or missing authentication
FORBIDDEN	403	Valid auth but insufficient permissions
NOT_FOUND	404	Requested resource does not exist
HASH_MISMATCH	409	Manifest hash does not match
SIGNATURE_INVALID	422	X-ROSIE-Signature verification failed

---

Related RFCs

• RFC-001: Data Standard — Data structures sent via these endpoints
• RFC-002: Engine Spec — Engine sequence diagrams utilizing these endpoints
• RFC-003: Evidence Standard — Evidence package uploaded via /evidence/upload