Explicable

Podcast 2 — In conversation

Speaker A: I used inexplicable in a report and my manager changed it to unexplained. Are they actually the same?

Speaker B: Not quite. Unexplained means no explanation has been given yet — it's a practical status. Inexplicable means no explanation could possibly satisfy — it implies something beyond ordinary reason. The distinction matters in formal writing.

Speaker A: So if a server goes down and nobody knows why, that's unexplained rather than inexplicable?

Speaker B: Exactly. Unexplained suggests the answer is out there but hasn't been found. Inexplicable suggests the thing defies explanation in principle — which is a much stronger claim. You'd use inexplicable for something genuinely mysterious, not just undiagnosed.

Speaker A: When would you actually use explicable rather than just saying explainable?

Speaker B: Explicable tends to appear in more formal registers — academic writing, legal analysis, philosophy. Explainable is more direct and modern. If you say this decision is explicable, you're writing in a style that expects the reader to appreciate the classical undertone. Explainable is plain English. Both are correct.

Speaker A: There's a whole field now called explainable AI. Should that be explicable AI?

Speaker B: Interestingly, the technical community settled on explainable as the standard term, often abbreviated XAI. But the underlying concept is identical to explicable in the classical sense — making the reasoning of a model unfoldable, visible, and testable. The philosophical heritage is the same even if the word choice is different.

Speaker A: Can you use explicable about a person's behaviour?

Speaker B: Yes. Her behaviour, though initially strange, proved entirely explicable once the context was known. It works well there because it implies the full structure of the situation was eventually unfolded. Unexplained would work too, but explicable in the passive here sounds more measured and deliberate.

Speaker A: Any common mistakes to watch for?

Speaker B: The main one is using inexplicable when you just mean surprising. Inexplicable is a strong philosophical claim. If something is merely unexpected or unusual, use surprising, puzzling, or hard to explain. Reserve inexplicable for things that genuinely resist all rational account. And remember: explicable is the rarer word, but the one that signals precision.

Podcast 3 — Prompt engineering

Build a React error display component and a Node.js API layer where every error returned to the frontend is explicable — each error object must include a human-readable reason field, a suggested remedy, and a link to relevant documentation. The API must never return a bare HTTP status code without an accompanying explicable reason. Store error definitions in a PostgreSQL table with code, message, cause, and remedy columns.

Build a React analytics dashboard where every data anomaly flagged in the charts is explicable through a drill-down panel. When a user clicks an anomaly marker, a side panel opens showing the contributing data points, the detection rule that triggered the flag, and a plain-English explanation of why the anomaly was considered significant. Backend in Node.js, data in PostgreSQL, anomaly rules stored as configurable thresholds per metric.

Design a PostgreSQL schema for an application audit log where every recorded state change is explicable — each audit record must include the previous state, the new state, the actor who made the change, the timestamp, and a mandatory reason field that cannot be null. Add a view that returns all state changes lacking an explicable reason for compliance review. Include indexes for actor, entity type, and timestamp for fast querying.

Build a full-stack explainable AI dashboard where every model prediction is rendered explicable to non-technical users. The React frontend shows each prediction alongside a feature importance chart, a plain-English summary of the top contributing factors, and a confidence score. The Node.js backend fetches prediction data from a model API and transforms raw SHAP values into explicable natural language summaries stored in PostgreSQL for caching and audit purposes.

Build a React HR admin interface for managing salary bands where every compensation decision is explicable and formally documented. Each employee record shows their current band, their position within it, and a mandatory justification field capturing why their salary was set where it is. The Node.js and PostgreSQL backend enforces that no salary update can be saved without an explicable reason. Generate a compliance report listing all records where the justification is missing or below a minimum length threshold.

Build a full-stack regulatory compliance platform where every administrative decision must be explicable and formally recorded before it can be actioned. The React frontend provides a decision form with structured fields: decision type, affected parties, legal basis, supporting evidence, and a free-text explicable reasoning field. Decisions cannot be submitted without all fields completed. The Node.js and PostgreSQL backend stores decisions, supporting documents, and generates a PDF summary of the explicable reasoning for each decision for external audit purposes.

Speaker B: Today we look at explicable in development prompts. The word does precise architectural work: it tells the model that wherever data, decisions, or errors appear in your system, they must carry their own explanation. Explicable means nothing is opaque — every output must be able to unfold itself.

Speaker A: So it shifts the model from building something that works to building something that shows its reasoning.

Speaker B: Exactly. First — an explicable error code system.

Speaker B: Saying every error is explicable tells the model you want structured error objects with cause and remedy, not bare status codes. The database table for error definitions emerges because explicable here means the explanation is a first-class data record, not an afterthought in a comment.

Speaker A: So the word makes the explanation part of the schema, not just the interface.

Speaker B: Second — a data anomaly drill-down dashboard.

Speaker B: Explicable through a drill-down panel tells the model the anomaly marker is not just a visual flag — it is a gateway to a full explanation. The contributing data points, detection rule, and plain-English summary all become required UI elements because explicable means the system must be able to justify every alert it raises.

Speaker A: Third — an audit log schema with explicable state changes.

Speaker B: The mandatory reason field that cannot be null combined with a view returning records that lack an explicable reason turns explainability into a database constraint. The model generates a NOT NULL column, a compliance view, and indexes because explicable here is enforced at the data layer, not just recommended in the UI.

Speaker A: Fourth — an explainable AI dashboard.

Speaker B: Every prediction rendered explicable to non-technical users tells the model it must translate raw SHAP values into natural language. The plain-English summary is not optional decoration — it is the definition of explicable for this system. The model generates a transformation layer and a caching table because explicable summaries need to be stored for audit just as much as the predictions themselves.

Speaker A: Fifth — an HR salary justification system.

Speaker B: No salary update can be saved without an explicable reason enforces the concept at the application logic level. The compliance report listing records with missing or short justifications makes the model generate both a validation rule and a reporting query. Explicable here becomes an operational gate — you cannot proceed without it.

Speaker A: And the final one — the regulatory decision platform.

Speaker B: Decisions cannot be submitted without all fields completed and must be explicable before they can be actioned makes explicability a workflow gate, not just a data field. The PDF summary for external audit takes the concept further: explicable reasoning must be portable, reproducible, and presentable to people outside the system. The model generates form validation, PDF generation, and document storage because explicable in a regulatory context is both a technical and legal requirement.

Speaker A: So explicable in a prompt always means: build the mechanism that shows the reasoning, not just the result.

Speaker B: That is the core architectural signal the word sends. When explicable appears in your prompt, the model understands you want a system where nothing is a black box. Every decision, every error, every anomaly, every prediction must carry the unfolded structure of its own reasoning. That is a different design requirement from correctness alone — it is the requirement of transparency.