delivery-harness
A reference implementation of AI guardrails designed for educational purposes, focused on delivery compensation scenarios. Its core design principle is that compensation amounts are determined by a deterministic rules engine while the AI model provides only recommendations, demonstrating how to safely separate deterministic logic from model inference in AI applications.
Timeline (last 90 days)
In the delivery-harness project, compensation amounts are determined by the rule engine, not by the model.
delivery-harness is positioned as a teaching MVP, not a production-ready delivery or compensation system.
The business tools in delivery-harness return synthetic data, state is mostly kept in memory, and there is no authentication, authorization, tenant isolation, or rate limiting.
delivery-harness revolves around two synchronous workflows—anomalous order analysis and compensation recommendations—with four locally registered tools covering orders, ETA, station capacity, and compensation rules.
For DAMAGED complaints, the caller must pass in damage_level (FULL or PARTIAL); when evidence is lacking, the policy returns zero compensation and requires human review.
The configuration item harness.compensation.approval-threshold has a default value of 10.0; compensation reaching or exceeding that amount requires a human approver.
When an optional dependency is unavailable during a completed workflow, the run is marked DEGRADED, deterministic results remain available, and affected steps are logged as failed.
The default HARNESS_LLM_ENDPOINT points to port 11434 on localhost, the example model is qwen2.5:7b, and the port in Compose is bound only to 127.0.0.1.
delivery-harness marks ingested knowledge documents as a "prompt injection trust boundary."
The needs_human_review and approval_required fields are derived jointly from guardrail results, parse success, model confidence, and consistency with the baseline, and are used for reporting only, not for authorization.
4 more timeline events
All Facts (14)
In the delivery-harness project, compensation amounts are determined by the rule engine, not by the model.
50%Unverifieddelivery-harness is positioned as a teaching MVP, not a production-ready delivery or compensation system.
50%UnverifiedThe business tools in delivery-harness return synthetic data, state is mostly kept in memory, and there is no authentication, authorization, tenant isolation, or rate limiting.
50%Unverifieddelivery-harness revolves around two synchronous workflows—anomalous order analysis and compensation recommendations—with four locally registered tools covering orders, ETA, station capacity, and compensation rules.
50%UnverifiedFor DAMAGED complaints, the caller must pass in damage_level (FULL or PARTIAL); when evidence is lacking, the policy returns zero compensation and requires human review.
50%UnverifiedThe configuration item harness.compensation.approval-threshold has a default value of 10.0; compensation reaching or exceeding that amount requires a human approver.
50%UnverifiedWhen an optional dependency is unavailable during a completed workflow, the run is marked DEGRADED, deterministic results remain available, and affected steps are logged as failed.
50%UnverifiedThe default HARNESS_LLM_ENDPOINT points to port 11434 on localhost, the example model is qwen2.5:7b, and the port in Compose is bound only to 127.0.0.1.
50%Unverifieddelivery-harness marks ingested knowledge documents as a "prompt injection trust boundary."
50%UnverifiedThe needs_human_review and approval_required fields are derived jointly from guardrail results, parse success, model confidence, and consistency with the baseline, and are used for reporting only, not for authorization.
50%UnverifiedThe delivery-harness test suite contains 112 tests; both workflows can be run end-to-end against a stub model transport layer without requiring Ollama or a Docker daemon.
50%UnverifiedEvaluation runs are performed in memory; when a use case declares no expectation the scorer reports "not measured" rather than awarding full marks, and the six synthetic use cases cannot establish accuracy.
50%UnverifiedCapabilities that delivery-harness explicitly does not claim to implement include: autonomous agent planning, production-grade tool integration, persistent storage, vector embeddings and Milvus RAG, authentication, rate limiting, distributed tracing, and automatic compensation execution.
50%UnverifiedIn delivery-harness, rules, documents, cases, evaluations, feedback, metrics, and traces are all lost on restart, and retrieval for CJK text is segmented only by spaces and punctuation rather than true tokenization.
50%