Solver as a Service
Sign Up Now →Sign Up Now
Solver as a Service Tutorial

Gaps found while walking the tutorial

Preview

These are repository observations at the time this tutorial was updated. They are work to close, not capabilities to claim:

  1. No solver-pack artifact upload/admission API. The server can register descriptors for assets it already sees, but a developer cannot upload an immutable config bundle, receive per-artifact validation, activate a version, or roll back by digest. This blocks the intended config-driven installation experience.

  2. No durable user-manifest CRUD on the server. The UX calls create, clone, update, and delete routes, while the server currently returns an empty list from GET /api/v1/user-manifests and exposes no matching write routes.

  3. Pack registration is not admission. An unresolved or malformed manifest is skipped during extension discovery; registration may still have returned success. Registration should return typed per-asset admission diagnostics.

  4. The authoring JSON Schema has drifted. Its constraint types, contract enum, and weight bounds do not describe several gated shipped manifests (including eligibility, current shared contract names, and measured competition weights). One schema and validator need to become authoritative.

  5. The runtime data contract remains partly duplicated. problem_inputs describes form controls, but required solver record sets are still enforced outside that surface in places. The manifest should expose one typed data schema consumed by server, worker, SDK, and UX.

  6. OpenAPI omits authentication security metadata. Generated clients therefore require manual authorization headers even though the service enforces tokens.

  7. ui.surfaces is discovery metadata, not a visualization contract. New pack types still need code-registry work for a specialized solution component.

  8. Result envelopes vary by handler. The UX currently probes several nesting shapes. A versioned normalized solution and certificate envelope should be generated and enforced across policies.

  9. There is no canonical persistent user-feedback contract. Suggestions and repair actions exist, but accepted/rejected schedules and user edits are not recorded through a shared reviewed surface.

Close these gaps in the shared schema, generator, server, or UX engine. Do not work around them in the retail pack.