The Complete sinc-LLM Signal Engineering Course

This course uses a signal-processing analogy to discuss task specification. The six-field format separates information to state before asking a model to perform the task.

The Nyquist-Shannon sampling theorem states that a bandlimited signal can be perfectly reconstructed from its samples if the sampling rate exceeds twice the signal's bandwidth. In mathematical form:

x(t) = Σ x(nT) · sinc((t - nT) / T)

where x(nT) are the sample values, T is the sampling period, and sinc(x) = sin(πx)/(πx) is the interpolation kernel. This formula reconstructs the continuous signal perfectly from discrete samples — but only if the sampling rate is high enough.

In the course’s analogy, a specification fragment supplies a task detail. A translation task and a production-API task require different details; the analogy does not establish a prompt sampling theorem.

The course uses “specification aliasing” to describe a mismatch between an intended task and an interpretation of an incomplete prompt. Prompt omissions are one issue to examine alongside sources, model behavior, and output checks.

The sinc-LLM format organizes prompts into PERSONA, CONTEXT, DATA, CONSTRAINTS, FORMAT, and TASK. These fields make requirements explicit; the signal reconstruction formula does not guarantee a correct or hallucination-free model response.

Review missing prompt details before execution and verify the response afterward. Prompt preparation and output checking are both parts of the workflow.

The format uses six fields: PERSONA, CONTEXT, DATA, CONSTRAINTS, FORMAT, and TASK.

The six fields and their specification roles:

Band 0: PERSONA

Defines the requested expertise, domain, and communication style.

Example: "Senior database engineer with 15 years of PostgreSQL optimization experience. You think in execution plans and index utilization patterns."

Band 1: CONTEXT

Defines the environment, situation, and relevant history.

Example: "Production PostgreSQL 15 database on AWS RDS, 200GB, 50M rows in the main table, peak 2000 QPS. Currently experiencing 99th percentile latency spikes during batch imports."

Band 2: DATA

Defines the input, format, sources, and relevant characteristics.

Example: "Input: CSV file with columns [user_id: int, event_type: enum, timestamp: ISO-8601, payload: JSON string]. 500K rows, ~200MB. Some rows have malformed JSON in the payload column."

Band 3: CONSTRAINTS

Defines requirements, prohibitions, and rules to check in the output.

A constraint such as “NEVER use SELECT *” states an exclusion that can be checked in the generated SQL.

Example: "MUST use parameterized queries. NEVER use string concatenation for SQL values. MUST include EXPLAIN ANALYZE for every query. MUST handle NULL comparisons with IS NULL. NEVER suggest indexes without estimating storage cost. MUST use explicit JOIN syntax."

Band 4: FORMAT

Defines the required schema, section order, and output structure.

Example: "Output: (1) Optimized query with inline comments, (2) EXPLAIN ANALYZE output interpretation, (3) Index recommendations as CREATE INDEX statements, (4) Before/after performance comparison table, (5) Migration script with UP and DOWN."

Band 5: TASK

States the objective explicitly alongside the other fields.

Example: "Optimize the slow query and provide migration scripts for the recommended schema changes."

Using the Fields Together

State the task details each field requires. An allocation or field count alone does not establish output quality or operating cost.

This module describes writing explicit constraints using requirements, prohibitions, and invariant rules.

Writing Explicit Constraints

Consider two prompts asking for the same code:

Weak prompt: "Write a Python function to process user data"

Strong prompt: Same task, but with constraints: "MUST validate all input types at function entry. MUST handle empty lists, None values, and dicts with missing keys. NEVER catch Exception broadly — catch specific exceptions only. MUST return typed NamedTuple, not raw dict. MUST include docstring with parameter types, return type, and raised exceptions."

Compare the two prompts against input handling, exception types, return type, and documentation requirements. Verify those requirements in the generated implementation.

The MUST/NEVER/ALWAYS pattern

Effective constraints follow three patterns:

• MUST — Positive requirements. Things that must be present in the output. "MUST include error handling for all I/O operations"
• NEVER — Hard exclusions. Things that must not appear. "NEVER use eval() or exec()"
• ALWAYS — Invariant behaviors. Things true for every instance. "ALWAYS validate input at trust boundaries"

The three patterns describe different types of requirements:

• MUST constraints are additive — they require the presence of something, narrowing the space by inclusion.
• NEVER states an exclusion that can be checked in the output.
• ALWAYS states a rule intended to apply to every relevant instance; define its scope explicitly.

Weak vs. Strong Constraints

Weak: "Handle errors properly" — This is not a constraint, it's a wish. The LLM's definition of "properly" may not match yours. This adds zero bits of specification information.

Strong: "MUST wrap all database calls in try/except with specific exception types (IntegrityError, OperationalError, ProgrammingError). MUST log the full exception with traceback to structlog. MUST return a typed error response with HTTP status code, error code string, and human-readable message. NEVER return stack traces to the client in production mode."

Weak: "Make it secure"

Strong: "MUST use parameterized queries for all database access. MUST sanitize all user input with bleach before rendering in HTML. MUST set Content-Security-Policy headers. NEVER store passwords in plaintext — use bcrypt with cost factor 12. MUST validate JWT tokens on every authenticated endpoint. NEVER log sensitive fields (password, SSN, credit card)."

Weak: "Write clean code"

Strong: "MUST keep functions under 20 lines. MUST have cyclomatic complexity under 10 per function. MUST use type hints on all function signatures. NEVER use single-letter variable names except for loop counters (i, j, k). MUST name booleans as questions (is_valid, has_permission, can_retry). MUST extract magic numbers into named constants."

The Constraint Density Rule

Constraint density is a proposed descriptive ratio of rule statements to prompt tokens. The numeric targets in this course are design assumptions, not validated output-quality thresholds.

Common Constraint Failures

1. Ambiguous scope: "MUST be efficient" — efficient in time? space? developer time? Specify the dimension.
2. Contradictory constraints: "MUST be concise" + "MUST include detailed explanations" — the LLM will satisfy one and violate the other unpredictably.
3. Unmeasurable constraints: "MUST be user-friendly" — how does the LLM verify this? Rewrite as: "MUST have error messages that state what went wrong, why, and how to fix it."
4. Over-constraining: Too many contradictory NEVER rules can make the output space empty, causing the LLM to violate constraints seemingly at random. If you have more than 20 constraints, check for contradictions.

In this course, SNR is a proposed measure of specification content relative to filler, ambiguity, and redundancy.

The SNR Formula

SNR = 10 · log10(P_signal / P_noise)  [measured in dB]

where:
  P_signal = tokens carrying specification information
  P_noise  = tokens carrying filler, ambiguity, or redundancy

The dB formula is used here as a signal-processing analogy. It does not establish typical prompt scores or a validated threshold for better output.

Zone Allocation

The course presents the following token allocations as design examples, not measured quality optima:

• Zone 1 (Z1) — proposed 5%: preamble and framing, including the formula declaration and structural markers.
• Zone 2 (Z2) — proposed 40%: context, persona, and data describing the operating environment.
• Zone 3 (Z3) — proposed 50%: constraints and output-format requirements.
• Zone 4 (Z4) — proposed 5%: task declaration.

Measuring SNR

To measure your prompt's SNR:

1. Count total tokens in your prompt (use any tokenizer — tiktoken for GPT, Anthropic's tokenizer for Claude).
2. Classify each sentence as signal (constrains the output space) or noise (filler, hedging, redundancy, politeness).
3. Calculate: SNR = 10 * log10(signal_tokens / noise_tokens)

Common noise patterns that reduce SNR:

• Politeness tokens: "Please", "Could you kindly", "I would appreciate if you" — these consume tokens without constraining output. Replace with direct instructions.
• Redundant instructions: "Make sure to double-check" after already saying "MUST verify" — the second instruction adds zero information.
• Vague qualifiers: "Try to", "If possible", "Ideally" — these signal that the constraint is optional, which the LLM interprets as permission to ignore it.
• Examples without purpose: Including examples that don't demonstrate edge cases or format requirements is noise. Every example should teach the LLM something it wouldn't know from the constraints alone.

Improving SNR

The fastest way to improve SNR is not to add more signal — it's to remove noise. Go through your prompt and delete every token that doesn't constrain the output space. Then rebalance the remaining tokens to match the zone allocation (Z1 5%, Z2 40%, Z3 50%, Z4 5%).

Review whether constraints are explicit, relevant, and noncontradictory. The course’s allocation targets are design examples to evaluate for the task.

Third-order optimization: check for constraint independence. If two constraints always co-occur (removing one makes the other meaningless), they should be merged into a single, stronger constraint. Independent constraints are more information-efficient because each one eliminates a different region of the output space.

The sinc-LLM framework includes a fine-tuned local model that can perform the scatter operation (raw prompt to sinc JSON decomposition) without calling any cloud API. This module covers how it was built and how you can replicate the process for your own domain.

Architecture: Qwen2.5-7B + LoRA

The scatter-model setup uses Qwen2.5-7B-Instruct, LoRA, Unsloth, and 4-bit quantized training on a consumer GPU.

Key specifications:

• Base model: Qwen2.5-7B-Instruct (7 billion parameters)
• Fine-tuning method: LoRA with rank 16, alpha 16, targeting q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
• Quantization: 4-bit NormalFloat (NF4) during training, GGUF Q5_K_M for inference
• Training data: raw-prompt and sinc-JSON pairs distilled from Claude.
• Training: measure duration on the selected hardware and configuration.
• Inference: measure latency and throughput for the workload and exported model.

Training Data: Distillation from Claude

The described training data pairs raw prompts with six-field sinc JSON responses from Claude Sonnet. The example domains include coding, writing, analysis, research, debugging, system design, and data science.

The distillation process:

1. Prompt collection: gather raw prompts across the intended task domains.
2. Teacher generation: Each prompt sent to Claude Sonnet with the scatter system prompt. The response is a complete sinc JSON object.
3. Quality filtering: Responses validated for correct JSON structure, all 6 bands present, CONSTRAINTS band is the longest, and constraint density above 0.03.
4. Format conversion: Pairs formatted as instruction-following examples: {{"instruction": raw_prompt, "output": sinc_json}}.

LoRA Configuration

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Qwen2.5-7B-Instruct",
    max_seq_length=4096,
    load_in_4bit=True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,                    # LoRA rank
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_alpha=16,
    lora_dropout=0,          # Optimized — no dropout needed for small datasets
    bias="none",
    use_gradient_checkpointing="unsloth",  # 60% less VRAM
)

GGUF Export for Ollama

After training, the model is exported to GGUF format for inference via Ollama:

# Export to GGUF Q5_K_M (best quality/speed tradeoff)
model.save_pretrained_gguf(
    "sinc-scatter-v1",
    tokenizer,
    quantization_method="q5_k_m"
)

# Create Ollama Modelfile
# FROM ./sinc-scatter-v1-Q5_K_M.gguf
# PARAMETER temperature 0.3
# PARAMETER top_p 0.9
# SYSTEM "You decompose raw prompts into 6-band sinc JSON..."

# Import into Ollama
# ollama create sinc-scatter -f Modelfile

Export the trained model to GGUF and check JSON structure, field completeness, and task-specific constraints. Compare outputs with the API option using the same workload.

When to use the local model vs. the API

• Local model: High-volume scatter (1000+ prompts/day), offline environments, air-gapped networks, latency-sensitive pipelines, cost-sensitive deployments.
• Cloud API: an option when a local GPU is unavailable or when evaluating API-based scatter. Compare outputs for the languages and tasks in scope.

This module covers deploying the sinc-LLM scatter service in production with FastAPI, nginx reverse proxy, SSL termination, rate limiting, and monitoring.

FastAPI Scatter Server

The core scatter service is a FastAPI application that accepts raw prompts and returns sinc JSON:

from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel
import subprocess, json

app = FastAPI(title="sinc-LLM Scatter API", version="1.0.0")

class ScatterRequest(BaseModel):
    prompt: str

class ScatterResponse(BaseModel):
    formula: str
    T: str
    fragments: list

@app.post("/api/scatter", response_model=ScatterResponse)
async def scatter(req: ScatterRequest):
    if not req.prompt.strip():
        raise HTTPException(400, "prompt cannot be empty")

    # Call local Ollama model
    result = subprocess.run(
        ["ollama", "run", "sinc-scatter", "--format", "json"],
        input=req.prompt, capture_output=True, text=True, timeout=30
    )
    return json.loads(result.stdout)

@app.get("/api/scatter/health")
async def health():
    return {"status": "ok", "version": "1.0.0", "model": "sinc-scatter-v1"}

nginx Reverse Proxy Configuration

nginx sits in front of FastAPI to handle SSL termination, static file serving, and rate limiting:

upstream scatter_api {
    server 127.0.0.1:8461;
}

# Rate limiting zone: 10 requests/second per IP
limit_req_zone $binary_remote_addr zone=scatter:10m rate=10r/s;

server {
    listen 443 ssl http2;
    server_name sincllm.com;

    ssl_certificate /etc/letsencrypt/live/sincllm.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sincllm.com/privkey.pem;

    # API proxy
    location /api/ {
        limit_req zone=scatter burst=20 nodelay;
        proxy_pass http://scatter_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 30s;
    }

    # Static frontend
    location / {
        root /var/www/tokencalc/frontend;
        try_files $uri $uri/ $uri.html =404;
    }
}

SSH Tunnel for Development

During development, you can access the remote scatter API via SSH tunnel without exposing it to the internet:

# Forward local port 8461 to the remote scatter API
ssh -L 8461:localhost:8461 root@your-server-ip

# Now access at http://localhost:8461/api/scatter/health

GPU Protection

The scatter model runs on GPU, which is a shared, expensive resource. Production deployments must protect the GPU from overload:

• Request queue: Use a semaphore to limit concurrent GPU requests (max 2-4 depending on VRAM).
• Timeout: Kill any scatter request that takes longer than 30 seconds — this prevents hung GPU processes from blocking the queue.
• Health monitoring: Check GPU memory usage every 60 seconds. If VRAM usage exceeds 90%, reject new requests with 503 until memory recovers.
• Graceful degradation: If the local model is unavailable, fall back to the cloud Claude API for scatter operations.

Monitoring and Alerting

Production scatter deployments should monitor:

• Request latency (p50, p95, p99): Target p95 under 3 seconds for local model, under 5 seconds for cloud fallback.
• Error rate: Alert if error rate exceeds 5% over any 5-minute window.
• GPU utilization: Track via nvidia-smi output. Sustained 95%+ utilization means you need to scale or throttle.
• Output quality: Periodically sample scatter outputs and verify they have all 6 bands, valid JSON structure, and constraint density above 0.03.
• Rate limit hits: Track how often users hit rate limits. If legitimate users are being throttled, increase limits or add caching.

Deployment Checklist

1. Install Ollama and import the sinc-scatter GGUF model.
2. Deploy the FastAPI scatter server with gunicorn/uvicorn (2-4 workers).
3. Configure nginx with SSL, rate limiting, and proxy_pass.
4. Set up systemd service files for automatic restart on failure.
5. Configure log rotation for access and error logs.
6. Set up monitoring dashboard (Grafana + Prometheus, or simple cron + Slack alerts).
7. Run load test: verify the system handles your expected QPS with acceptable latency.
8. Configure automated backups of the LoRA weights and training data.