Node 01
Separate request, evidence and training pathsDesign targets, stated honestly
Reliability and Operations
Reliability is treated as an engineering requirement: stateless request paths, isolated training workloads, explicit degradation behaviour when a model or connector is unavailable, monitored evidence pipelines and defined recovery objectives. PDICON does not currently publish a contractual uptime figure.
At a glance
What each figure means- Degradation
- Explicit
- Training isolation
- Separated
- Recovery
- Objective defined
- Uptime claim
- Not published
Unavailable model returns a stated fallback
Training load cannot degrade assistance
Agreed per deployment, not advertised
No SLA figure asserted before operation
System blueprint
A connected control plane, not a set of features.
Signals move forward; lineage and outcomes remain available to every governed stage.
Node 02
Monitor pipeline freshness and failuresNode 03
Define explicit degraded-mode behaviourNode 04
Alert on connector and model unavailabilityNode 05
Agree recovery objectives per deploymentNode 06
Report against measured operationAn unavailable model must fail visibly
Silent degradation is worse than an outage.
If a model or connector is unavailable, the interface states it plainly instead of returning a lower-quality answer that looks identical to a good one. Engineers need to know what they are trusting.
Training must not starve assistance
GPU work is isolated from the request path.
Training and evaluation jobs run on separate capacity so that a long training run cannot slow the assistance that people depend on during a working day.
No uptime theatre
A number without operating history is marketing.
Publishing a contractual availability figure before running production workloads would be dishonest. Recovery objectives are agreed per deployment and reported against real operation.
Operating matrix
Evidence moves through explicit controls.
The matrix separates source evidence, intelligence work, governing authority and the resulting artifact.
| Subject | Input | Intelligence operation | Human / policy control | Output |
|---|---|---|---|---|
| Assistance path | User request | Stateless serving | Health monitoring | Predictable response |
| Evidence pipeline | Source ingest | Freshness checks | Failure alerting | Trustworthy inputs |
| Training workload | Dataset version | Isolated GPU execution | Capacity separation | No user impact |
| Degraded mode | Component failure | Stated fallback | Visible notice | Informed user |
Design boundary
What the system will not pretend to be.
Credibility begins where automation stops and accountable professional judgment starts.
No published uptime percentage
PDICON will not assert an availability figure it has not operated long enough to measure.
No silent fallback
A degraded result is labelled as degraded rather than presented as a normal answer.
No unlimited scale claim
Capacity limits are agreed per deployment and stated openly.
Questions answered
Precise answers for technical evaluation.
Open a question to inspect the operating position, not a marketing promise.
01What uptime do you guarantee?
None is published yet. Asserting an availability figure without production operating history would be misleading; recovery objectives are agreed per deployment instead.
02What happens if a model is unavailable?
The interface states the degradation explicitly rather than silently returning a weaker answer.
Get started
Start with one real decision.
Bring a workflow your team already repeats. We define the evidence, the approver and the outcome to measure, then instrument it end to end.
Talk to the team How engagements work
We are working with a small number of design partners across engineering and procurement workflows.