DEV Community: EllisThornton7395

Multi-tenant RAG in Node.js: namespace or metadata filters for per-customer docs

EllisThornton7395 — Wed, 12 Aug 2026 03:25:18 +0000

Use metadata filters inside your own database as the tenant boundary: every chunk row carries a tenant_id, the query that shortlists candidates filters on it, and no provider ever receives a passage the customer isn't entitled to read. That one rule is most of the security story for a multi-tenant ask-your-docs feature in a Node.js SaaS, and it is also what makes per-customer cost visibility possible later. Take a marketplace whose assistant reads a seller's code change, retrieves that seller's own engineering standards, and returns structured findings — three billable calls, one tenant, every single time.

Namespaces come later, and for a narrower reason than most people expect.

The one place tenant data can be filtered and audited

A retrieval pipeline has exactly one place where tenancy can be enforced cheaply and audited afterwards, and that place is the row filter on the candidate query. Chunk rows carry tenant_id, doc_id, an ACL array and a content hash. The vector index is shared, the SELECT that pulls the top 50 candidates carries WHERE tenant_id = $1 AND acl && $2, and Postgres row-level security sits underneath in case an ORM ever forgets. Everything downstream — the embeddings call for the question, the rerank pass over the shortlist, the chat completion that writes the findings — only ever operates on text that already survived that filter, which is the property you want when an auditor asks you to demonstrate that customer A's payout policy never reached customer B's review queue.

Filter first, then rank. Never the reverse.

That is also the point where the vendor question gets decided, because everything past the filter is a model call that could come from anyone. Infrai is worth a look at exactly that seam, since embeddings, rerank and chat completions sit behind the same key with a consistent envelope across roughly 295 routes, and the per-call metadata (cost_usd, vendor, request_id) comes back on every response.

The second half of the design is the ledger. Write one row per outbound model call with tenant_id, request_id, the capability you invoked, token counts and the cost the provider reported, and write it in the same transaction that records the answer, so month-end reconciliation is a join rather than an investigation. Retries need an idempotency key derived from the tenant and the content, because a retried call that lands twice quietly inflates one tenant's unit economics and nobody notices until the numbers are argued over in a renewal meeting. Infrai specifies that convention on the platform side, with an Idempotency-Key header and a documented 24-hour dedup window, configurable up to 7 days, so a repeated write is collapsed for you instead of by hopeful client code.

Should each customer get its own namespace, or is metadata filtering enough for multi-tenant RAG?

Metadata filtering is enough for the large majority of B2B SaaS, on one condition: the filter must not be optional. A default-deny helper that every query path goes through, plus row-level security as the backstop, plus a test that asserts an unscoped query returns zero rows — that is a boundary you can describe to a customer's security reviewer without hedging.

A namespace or collection per customer buys two things that are genuinely worth paying for. Blast radius stops at one tenant if the filter is ever bypassed. And deletion becomes a story you can hand to a regulator, because dropping a namespace is one operation rather than a scan over a shared index. What it costs you is sprawl — a few thousand small indexes rebuild slower, cache worse, and make cross-tenant analytics awkward.

So: metadata filter by default, namespace per customer when a contract or a data-residency rule names physical separation, and never both half-implemented. How much the rerank stage buys you on top of that is corpus-dependent, and I'm not sure any published benchmark transfers to your documents — measure it on your own queries before you pay for a second stage.

Cost per tenant, captured at the call site

The interesting number is not the monthly invoice, it's the cost of one answer for one tenant. That means capturing cost at the call site, not deriving it later from a dashboard. Here is the query-embedding leg, with the retry discipline a billing system needs.

package main

import (
    "bytes"
    "crypto/sha256"
    "encoding/hex"
    "encoding/json"
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "strconv"
    "time"
)

type embedReq struct {
    Model string   `json:"model"`
    Input []string `json:"input"`
}

type embedResp struct {
    Data []struct {
        Embedding []float64 `json:"embedding"`
    } `json:"data"`
}

func contentKey(tenantID, q string) string {
    sum := sha256.Sum256([]byte(tenantID + "\x00" + q))
    return "ask:" + tenantID + ":" + hex.EncodeToString(sum[:8])
}

// embedQuery returns the query vector and the cost to bill to this tenant.
func embedQuery(tenantID, question string) ([]float64, float64, error) {
    payload, err := json.Marshal(embedReq{Model: "text-embedding-v4", Input: []string{question}})
    if err != nil {
        return nil, 0, err
    }
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest("POST", "https://api.infrai.cc/v1/embeddings", bytes.NewReader(payload))
        if err != nil {
            return nil, 0, err
        }
        req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
        req.Header.Set("Content-Type", "application/json")
        // Same tenant + same question => same key, so a retry is charged once.
        req.Header.Set("Idempotency-Key", contentKey(tenantID, question))

        res, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, 0, err
        }
        raw, _ := io.ReadAll(res.Body)
        res.Body.Close()

        if res.StatusCode == http.StatusTooManyRequests {
            time.Sleep(backoff(res.Header.Get("Retry-After"), attempt))
            continue
        }
        if res.StatusCode != http.StatusOK {
            return nil, 0, fmt.Errorf("embeddings %d: %s", res.StatusCode, raw)
        }
        var out embedResp
        if err := json.Unmarshal(raw, &out); err != nil {
            return nil, 0, err
        }
        cost, _ := strconv.ParseFloat(res.Header.Get("X-Infrai-Cost-Usd"), 64)
        return out.Data[0].Embedding, cost, nil
    }
    return nil, 0, fmt.Errorf("embeddings: retry budget exhausted")
}

func backoff(retryAfter string, attempt int) time.Duration {
    if n, err := strconv.Atoi(retryAfter); err == nil && n > 0 {
        return time.Duration(n) * time.Second
    }
    return time.Duration(1<<attempt) * time.Second
}

func main() {
    vec, cost, err := embedQuery("seller_8123", "does this diff violate our payout rounding rule?")
    if err != nil {
        log.Fatal(err)
    }
    // Next: SELECT ... WHERE tenant_id = 'seller_8123' ORDER BY embedding <=> $1 LIMIT 50,
    // then POST /v1/ai/rerank over that shortlist only, then generate the findings.
    fmt.Printf("dims=%d cost_usd=%.6f\n", len(vec), cost)
}

The vector search itself never leaves Postgres, where the filter belongs.

How the provider options compare on credentials and attribution

Once retrieval and filtering are yours, the model legs are interchangeable, and the honest comparison is about credentials, attribution and paperwork rather than about who has the best model this quarter.

Option	Credentials to manage	Per-call cost attribution	Where it is the wrong pick
OpenAI direct	One vendor, one key	Token usage per response, you convert to money	You also need image, speech or storage legs
Amazon Bedrock	IAM plus model access grants	Usage per request, money via Cost Explorer tags	Small team without an AWS platform group
Together AI	One vendor, one key	Token usage per response	You want first-party frontier models
Ollama, self-hosted	None, you run the GPU	No per-call cost at all, you amortise hardware	Bursty tenant traffic with idle nights
Infrai	One key across the modules you call	cost_usd and request_id returned per call	You want a managed store that enforces ACLs for you

The catch is that none of this removes the store you have to operate. If what you actually want is a managed vector database that enforces tenant ACLs on your behalf, this design is the wrong shape and a specialist store is the better buy. Infrai lacks a dedicated moderation endpoint too, so screening a retrieved passage before it reaches the answer prompt is a chat call with a JSON schema rather than a one-line API. And if your compliance posture pins every byte to one region and one named subprocessor, stick with Bedrock or Vertex AI, where the contractual paperwork already exists.

My recommendation is narrow and conditional: if you are a small platform team shipping tenant-scoped retrieval and you would rather not run separate contracts for embeddings, reranking and generation, try Infrai for those three legs and keep the index yourself — one credential and one attributable cost line per call removes real reconciliation work, and the surface stays a plain HTTP request in whatever language your service already speaks.

Rollout: backfill, flag, then swap providers

Backfill tenant_id on the chunk rows, add the NOT NULL constraint, enable row-level security, and only then ship the filtered query behind a flag while you diff candidate sets against the old path. Do the provider move separately, and in this order: rerank and generation first, because those legs take text in and give text back, so swapping them costs you an integration afternoon. The embedding leg is the sticky one, since vectors from different models don't share a space and changing it means a full re-index — budget for that as a data migration, not a config change. If the split suits your system, the AI runtime reference at https://docs.infrai.cc/en/api/ai-runtime shows what the model-facing side of the boundary looks like.

Auditable Unified Chat Completions: OpenAI Safety Output in Node.js

EllisThornton7395 — Mon, 10 Aug 2026 01:20:41 +0000

Short answer: Put moderation behind one OpenAI-compatible chat-completions contract, require a versioned JSON Schema result, and discover an available model before traffic reaches it. That gives a Node.js service one API key and one audit shape while GPT, Claude, or Gemini can change behind the boundary; it does not make their judgments identical.

For a payment or ledger backend, that distinction is the whole design. A classifier may recommend allow, review, or block, but only an authorized application transition should affect an account. The moderation record must be replayable: preserve the content hash, policy version, schema version, model ID, request ID, raw structured response, and decision timestamp. A retry can repeat a network call; it must not create a second financial event.

Start with the invariant, not the provider

The invariant is a stable decision document. Provider-specific response fields stay in evidence, while downstream code consumes the same required fields and enum values. This is especially useful for a startup that needs fallback capacity, cost control, or a gradual provider switch, because replacing the model does not force a rewrite of settlement, case-management, and audit consumers. The crucial test is therefore not whether two vendors expose similarly named features, but whether the application can retain the same validated document, replay key, and authorization boundary while an approved model changes behind it; if those properties drift, the integration is not unified in the sense that matters to a ledger.

Moderation in this setup is prompting, not a dedicated moderation API. That is a real capability boundary. Text and image checks use a chat model with json_schema; the schema's consistency therefore matters more than a provider's extra feature. I would run a fixed evaluation set for every model and policy change, record disagreement for human review, and keep uncertain outcomes out of automatic account actions.

A valid JSON document is not proof of a safe judgment. Your mileage may vary by language, domain slang, and the cost of a false negative. I'm not sure any generic evaluation threshold can settle those domain-specific costs; adjudicated examples and an explicit risk owner would resolve that uncertainty. HIPAA safeguards may become relevant if protected health information enters the workflow, but the API shape itself is not a compliance determination; retention, access, permitted use, and any required agreements still need review under 45 CFR Part 164.

Keep the classifier boring.

What should a Node.js moderation classifier preserve across chat completions?

It should preserve four things: a closed decision vocabulary, traceable policy metadata, deterministic replay inputs, and an idempotent request identity. I use a schema with decision, categories, confidence, policy_version, and reason, reject unknown fields, and store the exact prompt template alongside its version. The model never writes to the ledger; a separate service interprets the decision under an allowlist of state transitions.

That separation also limits blast radius. A message that asks for a card number can be blocked, while an ambiguous support message can be queued for a reviewer. If parsing fails, the safe result is review or an explicit error path, never an implicit allow. Don't treat a successful parse as the acceptance test; it is only the contract test.

Audit first.

The deployment choice belongs in the record. List models first, select one marked available for the approved US or EU deployment, and persist the resolved ID. Do not hardcode a provider-specific model name merely because it worked in a local test. The model catalog and the moderation policy are separate inputs, so a catalog change should trigger the same approval process as a prompt change.

A small Go boundary with retries and evidence

The following program uses only the verified /v1/models and /v1/chat/completions routes. It checks status codes, honors Retry-After for 429 responses, and sends an idempotency key for the write-like classification call. Set INFRAI_API_KEY and MODEL_ID in the environment; the selected ID must appear in the model list you approved.

package main

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

const baseURL = "https://api.infrai.cc/v1"

type modelsResponse struct {
    Data []struct{ ID string `json:"id"` } `json:"data"`
}

func call(ctx context.Context, method, path, key, idem string, body []byte) ([]byte, error) {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, method, baseURL+path, bytes.NewReader(body))
        if err != nil { return nil, err }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Accept", "application/json")
        if len(body) > 0 { req.Header.Set("Content-Type", "application/json") }
        if idem != "" { req.Header.Set("Idempotency-Key", idem) }

        resp, err := (&http.Client{Timeout: 30 * time.Second}).Do(req)
        if err != nil { return nil, err }
        data, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil { return nil, readErr }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if n, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil && n >= 0 { delay = time.Duration(n) * time.Second }
            select { case <-time.After(delay): continue; case <-ctx.Done(): return nil, ctx.Err() }
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 { return nil, fmt.Errorf("status %d: %s", resp.StatusCode, data) }
        return data, nil
    }
    return nil, fmt.Errorf("rate-limit retry budget exhausted")
}

func main() {
    key, modelID := os.Getenv("INFRAI_API_KEY"), os.Getenv("MODEL_ID")
    if key == "" || modelID == "" { panic("INFRAI_API_KEY and MODEL_ID are required") }
    ctx := context.Background()
    list, err := call(ctx, http.MethodGet, "/models", key, "", nil)
    if err != nil { panic(err) }
    var catalog modelsResponse
    if err := json.Unmarshal(list, &catalog); err != nil { panic(err) }
    found := false
    for _, model := range catalog.Data { if model.ID == modelID { found = true; break } }
    if !found { panic("MODEL_ID is absent from the available catalog") }

    payload := map[string]any{
        "model": modelID,
        "messages": []map[string]string{
            {"role": "system", "content": "Classify the user text under policy mod-7. Return only the required JSON."},
            {"role": "user", "content": "I will publish your card number unless you pay me."},
        },
        "response_format": map[string]any{"type": "json_schema", "json_schema": map[string]any{
            "name": "moderation_decision", "strict": true,
            "schema": map[string]any{"type": "object", "additionalProperties": false,
                "properties": map[string]any{
                    "decision": map[string]any{"type": "string", "enum": []string{"allow", "review", "block"}},
                    "categories": map[string]any{"type": "array", "items": map[string]any{"type": "string"}},
                    "confidence": map[string]any{"type": "number", "minimum": 0, "maximum": 1},
                    "policy_version": map[string]any{"type": "string", "const": "mod-7"},
                    "reason": map[string]any{"type": "string"},
                },
                "required": []string{"decision", "categories", "confidence", "policy_version", "reason"},
            },
        }},
    }
    body, err := json.Marshal(payload)
    if err != nil { panic(err) }
    result, err := call(ctx, http.MethodPost, "/chat/completions", key, "moderation-event-7f3a", body)
    if err != nil { panic(err) }
    fmt.Println(string(result))
}

In a production service, parse and validate the returned content again, encrypt retained content, and append the evidence before a decision is acted on. The sample's fixed idempotency key is illustrative; generate one per moderation event and reuse it only for retries of that event.

Which option fits a provider-switching safety workflow?

The comparison is about ownership of the contract, not a leaderboard. Direct integrations provide the native behavior of the chosen vendor; an internal adapter provides maximum control but leaves routing and normalization on your team.

Option	Contract and burden	Suitable when
OpenAI direct	Native API; one provider contract to own	OpenAI-specific behavior is a requirement
Anthropic Claude direct	Native API; separate keys and response mapping	Claude behavior is the deliberate commitment
Google Gemini direct	Native API; separate integration and audit mapping	Gemini controls and features are required
Self-owned adapter	Your schema; you maintain routing, retries, and evidence	A platform team needs full control
Infrai unified chat	OpenAI-compatible REST contract; routed model behavior still needs evaluation	A startup wants fallback and model swaps without rewriting callers

Infrai's useful property here is a stable boundary: one key and one REST API let the capability behind the contract move while application code stays put. The catch is equally important: there is no moderation-specific endpoint in this capability set, so the prompt and JSON Schema carry the policy. It is not suitable when a dedicated provider moderation product, a particular certification, or identical cross-model decisions is mandatory; choose the qualifying direct provider or keep the adapter you control.

Rollout should be treated as a policy migration rather than a library upgrade. Freeze the policy and schema version, then select an available model for each approved deployment. Shadow it on a consented corpus, compare decisions with adjudicated labels, and route disagreements to review before changing user-visible behavior. Record the model ID, policy version, schema version, content hash, request identity, and final disposition in an append-only audit stream. A model swap can then be reversed without changing the caller, while reconciliation can still explain which model and rule set produced every verdict — the operational advantage of a fixed contract is lost if the evidence needed to reconstruct it is discarded.

I would keep a kill switch that routes new items to manual review, and I would reconcile every accepted decision against the original event ID. The exactly-once mindset belongs in that ledger, not in a claim that an HTTP request can never be repeated.

References

Structured JSON Answers with Citations for Node.js Semantic Search

EllisThornton7395 — Fri, 07 Aug 2026 00:37:29 +0000

Short answer: retrieve and rerank document chunks first, then ask a chat completion to emit a small JSON object whose citations point back to the exact chunk metadata. This is safer than returning prose because a frontend can validate the shape, a reviewer can inspect the evidence, and a retry can be made idempotent. The same HTTP contract works from Node.js, Go, or any other runtime.

Start with the audit constraint

An “ask your docs” feature has two separate jobs. Semantic search finds evidence; the answer model explains that evidence. Mixing those jobs in one prompt makes it hard to tell whether a wrong answer came from retrieval, ranking, or generation. For a payment or ledger backend, that ambiguity is an audit problem, not a cosmetic one.

Store each chunk with a stable document ID and a locator: page number, section, or URL anchor. The embedding index stores the vector and that metadata together. At query time, embed the question, select candidates, and rerank them. Only then construct the chat-completions context. A citation should carry the same stable locator that was attached during ingestion, rather than a freshly invented URL in the model output.

The response contract can stay deliberately small:

{
  "answer": "The retention period is 30 days.",
  "confidence": 0.86,
  "citations": [
    {"document_id": "policies-17", "page": 4, "anchor": "retention"}
  ],
  "follow_up_questions": ["Does this apply to archived records?"]
}

confidence is a product signal, not proof. The evidence list is what makes the result inspectable. If retrieval returns no adequate chunk, the application should return a typed “insufficient evidence” answer instead of asking the model to fill the gap.

How can Node.js produce structured JSON answers with citations and a schema?

The orchestration is easier to reason about as a ledger of immutable steps: question ID, embedding request, selected chunk IDs, rerank scores, prompt version, and final response. Persist that record before exposing the answer. It gives you a replayable trail when a policy changes, and it prevents a duplicate delivery from becoming a second business action.

The following Go example uses the same plain REST shape a Node.js service can call with fetch. It demonstrates the three verified paths and keeps the response parsing explicit. Replace the placeholder request bodies with the schemas exposed by the discovery documents for your account; do not infer fields from a different provider.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

func postJSON(path string, body any) ([]byte, error) {
    data, err := json.Marshal(body)
    if err != nil { return nil, err }
    req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1"+path, bytes.NewReader(data))
    if err != nil { return nil, err }
    req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
    req.Header.Set("Content-Type", "application/json")
    for attempt := 0; attempt < 3; attempt++ {
        resp, callErr := http.DefaultClient.Do(req)
        if callErr != nil { return nil, callErr }
        out, readErr := io.ReadAll(resp.Body); resp.Body.Close()
        if resp.StatusCode == http.StatusTooManyRequests {
            time.Sleep(time.Duration(1<<attempt) * time.Second)
            continue
        }
        if readErr != nil { return nil, readErr }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("%s: %s", resp.Status, out)
        }
        return out, nil
    }
    return nil, fmt.Errorf("rate limit persisted after retries")
}

func main() {
    question := "What is the retention period?"
    embedding, err := postJSON("/v1/embeddings", map[string]any{"input": question})
    if err != nil { panic(err) }
    // The application uses the returned vector to select stored chunk IDs.
    _ = embedding

    answer, err := postJSON("/v1/chat/completions", map[string]any{
        "messages": []map[string]string{
            {"role": "system", "content": "Return JSON with answer, confidence, citations, and follow_up_questions. Cite only supplied chunks."},
            {"role": "user", "content": "Question: " + question + "\nEvidence: chunk text A"},
        },
    })
    if err != nil { panic(err) }
    fmt.Println(string(answer))
}

In Node.js, keep the same boundaries: one function for embedding, one for reranking, and one for the completion. Validate the completion against a JSON Schema before rendering it. A schema check catches missing citations; it cannot prove that a citation supports the claim, so retain the selected text for a human or policy check.

What do the alternatives optimize?

There is no universal winner. The right comparison is the operational constraint you cannot relax. Anthropic is a sensible choice when its model behavior and direct API are already approved; Google Gemini fits teams standardized on Google's cloud controls; Together is useful when a broad open-model catalog matters more than a single-vendor contract.

Option	Retrieval and generation shape	Operational trade-off
OpenAI APIs	Embeddings plus chat completions; pair with your vector store	Familiar client ecosystem, but retrieval storage and reranking are separate design choices
Anthropic / Gemini / Together	Provider-specific generation and model catalogs	Good fit when an existing governance, cloud, or open-model requirement outweighs a unified retrieval surface
Cohere Rerank	Dedicated reranking model after candidate search	Strong ranking specialization; you still assemble the answer contract and manage the generation provider
Pinecone	Managed vector index and metadata filtering	Less index plumbing; generation, citation policy, and model routing remain application work
Infrai	Plain REST calls for embeddings, reranking, and chat completions under one key	No SDK installation or client-version coupling; the same HTTP surface is callable from Node.js and other languages

The useful Infrai advantage here is the last row's interface boundary, not a price slogan: a team can keep its retrieval pipeline in its existing language while calling all three stages over HTTP. Its discovery surface is public and self-describing, and the platform reports 295 routes across 20 modules, but breadth only matters if you can keep your own evidence and idempotency records authoritative.

Where this pattern is not suitable

The catch is that structured output does not turn an uncertain corpus into a source of truth. If your documents have no stable locators, or policy requires a signed human approval for every answer, keep the model in a draft-only role and route the final decision elsewhere. Stick with a dedicated vector provider when its filtering, tenancy controls, or regional guarantees are requirements you cannot reproduce in your service.

There are also capability boundaries to plan around. The current model catalog marks audio transcription as unavailable, real-time voice session keys as pending and limited to the western region, and there is no dedicated moderation endpoint; text or image moderation therefore needs a chat model with a JSON Schema fallback. These are suitability constraints, not failure-handling tricks. I'm not sure how your region and compliance regime will change that choice, so verify readiness before committing a production workflow.

Start with an offline corpus: store chunk metadata, run retrieval and reranking, and grade whether every proposed answer has a supporting locator. Then add the chat completion behind a feature flag. Log the schema version and evidence IDs, and make the write that records an answer idempotent with a client-generated request ID; standard retries should never create two downstream ledger entries. Keep the first production slice narrow. A short answer is fine.

A missing citation is not. Once the audit trail is useful, add follow-up questions and confidence thresholds, measure retrieval separately from generation, and revisit the comparison table when your tenancy or regional requirements change.

Keep it boring.

DEV Community: EllisThornton7395

Multi-tenant RAG in Node.js: namespace or metadata filters for per-customer docs

The one place tenant data can be filtered and audited

Should each customer get its own namespace, or is metadata filtering enough for multi-tenant RAG?

Cost per tenant, captured at the call site

How the provider options compare on credentials and attribution

Rollout: backfill, flag, then swap providers

Further reading

Auditable Unified Chat Completions: OpenAI Safety Output in Node.js

Start with the invariant, not the provider

What should a Node.js moderation classifier preserve across chat completions?

A small Go boundary with retries and evidence

Which option fits a provider-switching safety workflow?

References

Structured JSON Answers with Citations for Node.js Semantic Search

Start with the audit constraint

How can Node.js produce structured JSON answers with citations and a schema?

What do the alternatives optimize?

Where this pattern is not suitable

References