Shipwright: Craft, Software & Verification
- Shipwright is a multidisciplinary term referring to tacit expertise in traditional shipbuilding, automated Dockerfile repair, and formal methods for distributed systems.
- In maritime contexts, Shipwright denotes the master craftsperson whose experiential knowledge ensures quality construction and safety through intergenerational training.
- In digital domains, the concept operationalizes complex tasks via neural network anomaly detection and rigorous verification frameworks for Byzantine fault-tolerance.
Shipwright is used in recent technical literature in three distinct senses. In shipbuilding, it denotes the experienced craft role through which tacit production knowledge and apprenticeship are transmitted across generations, especially in traditional wooden dhow construction in Kerala (Sangeet et al., 2023). In software engineering, “Shipwright” denotes a human-in-the-loop system for Dockerfile repair that combines build-log embeddings, clustering, search, and rule-based transformations (Henkel et al., 2021). In formal methods, “Shipwright” also denotes a verification framework for proving correctness and liveness of distributed systems with Byzantine participants, with PBFT as the main case study (Leung et al., 18 Jul 2025). A plausible commonality across these usages is the attempt to convert difficult, failure-prone practical knowledge into reusable operational structure.
1. Maritime craft role and tacit expertise
Within shipbuilding, the shipwright is presented as a carrier of highly specific experiential knowledge that is not exhausted by formal procedure. The relevant literature emphasizes that when an experienced hand retires, transfers, or leaves, an establishment suffers a “severe loss,” because the detailed judgments associated with that position make work more efficient. In shipyard practice, those judgments include what to weld first, how to sequence outfit work, how to recognize a likely error early, and how to solve recurring problems under real yard conditions. The loss is framed not only as an efficiency problem but also as a quality- and safety-related problem, since better capture of expertise is associated with improved production and compliance with acceptable standards enforced by classification societies (Sangeet et al., 2023).
The traditional wooden dhow builders of Kerala provide the paper’s clearest account of shipwright expertise as an intergenerational craft institution. The head shipwright, called the Moothasari, trains an apprentice who works with him for more than half of the mentor’s working tenure and eventually succeeds him. This apprenticeship structure is treated as an ideal setting for transmitting tacit knowledge because learning occurs through prolonged exposure to actual work and decision-making rather than through isolated documentation. The account therefore resists a common misconception that shipbuilding knowledge is reducible to drawings, checklists, or formal process descriptions alone.
2. Digital preservation of shipwright knowledge in shipbuilding
The proposed response to expertise loss in shipbuilding is a knowledge-based management system backed by an artificial neural network. Its intended workflow is explicit: collect work logs and issues from employees, build a structured database, train a neural network on the accumulated cases, recognize patterns in new problems, and return likely solutions or prior similar cases. A new worker would enter the difficulty being faced, and the system would search prior data for a match or near-match. If a prior case exists, the system could suggest the earlier solution, reducing trial-and-error and speeding decision-making. The paper connects this mechanism to deep learning and backpropagation, and states that the network should calculate dependencies between data from different hierarchical positions such as design, production, and outfit departments (Sangeet et al., 2023).
Anomaly detection is central to that proposal because shipbuilding data are not uniform across vessels or yards. The paper distinguishes normal data, point anomalies, and collective anomalies. It further argues that if observations follow a stochastic model, statistical analysis can forecast further data points while allowing for occasional anomalies, and that a trained ANN could forecast the shipbuilding timeline and identify problems that might otherwise be overlooked. Microsoft SharePoint is presented as the practical data-entry platform for workers to log daily decisions, actions taken, and resulting effects; MATLAB is cited as a tool for analysis, ANN training and testing, and pattern recognition. The paper also describes a GUI-based interface in which a user logs in as a shipyard employee, selects a sub-department, enters an anomaly and keywords, searches for exact and/or keyword matches, adds a new entry if no result is found, records teammates involved, enters start and end times, selects project number and yard number, adds remarks and attachments, and submits the record.
The implementation sequence is also given in stepwise form: training of personnel infrastructure HR allocation; database review team; database incubation; periodical analysis of data points; minimum database collected; integration of neural network into the database system recognising parameters; setting up input/output; defining neural network dynamics; training the network; pattern recognition; and suggestion of solutions as output. A significant practical constraint is that the network would require at least a decade to be properly trained, because accuracy improves only when more data points are added and the network definition is sound. For that reason, the paper argues that implementation in a single shipyard would be wasteful, whereas a consortium of many shipyards or a non-profit organization funded and run by classification societies and institutions such as RINA could create a global KBMS with better prediction accuracy, production efficiency, communication of practices among shipyards, and compliance with changing IMO/IACS requirements. Immediate implementation in the traditional dhow setting is described as uncertain because it would require an overseeing body, technical support, more resources, and funding; by contrast, design software used widely across modern shipyards is presented as the most economical and realistic starting point.
3. Shipwright as a human-in-the-loop Dockerfile repair system
In software engineering, Shipwright is a repair-oriented system for broken Dockerfiles. The motivating empirical result is that over a quarter of the examined Dockerfiles failed to build, which directly undermines Docker’s promise of reproducibility and portability. The paper’s workflow has three stages. First, it mines Dockerfiles from GitHub, builds them in context, and records logs and metadata for successful and failing builds. Second, it embeds build logs with a modified BERT model, clusters broken Dockerfiles with HDBSCAN, and uses a human-in-the-loop process to inspect clusters, search for known causes and solutions, and encode those solutions as repair or suggestion patterns. Third, for a new broken Dockerfile, it matches the static Dockerfile text and dynamic build log against its database of patterns; if a repair is available, it applies it, and if not, it can return a suggestion or curated search results (Henkel et al., 2021).
The data-collection scale is substantial. The filtered dataset contained 32,466 repositories/Dockerfiles. The authors attempted 20,526 builds, found 5,405 broken Dockerfiles, estimated a 26.3% breakage rate, and also reported 393 timed-out builds and 3,514 undetermined builds. For each build they stored stdout/stderr logs, the Dockerfile AST, repository metadata, image history, and clone/build information. Build logs serve as the main symptom signal for later clustering.
The embedding stage uses a BERT variant suited for sentence embeddings, inspired by Sentence-BERT. Before embedding, Shipwright normalizes logs by splitting on snake_case and camelCase, splitting on operators that may appear in code snippets, lowercasing input, removing repetitive whitespace, and stripping certain special or unicode characters. It then uses the last few lines of the error log as the embedding input. HDBSCAN is chosen because failure types are noisy and irregular: it discovers clusters of arbitrary shape, handles noise and outliers, and does not force every point into a cluster. In the best configuration reported, HDBSCAN clustered 34% of the broken Dockerfiles on average, and 36.5% of clusters were confirmed to be rooted in a single common cause.
4. Repair patterns, suggestions, and empirical performance
Shipwright records a repair as a pattern paired with a repair function. The pattern is a regular expression over the Dockerfile and/or build log, while the repair function is a transformation over the Dockerfile using operations such as add, remove, and replace. The paper states that Shipwright supports 13 repair patterns. Because many failures are not safely automatable, it also supports 50 suggestion patterns for cases such as broken application code, broken URLs, or compilation failures inside the project. This design makes explicit that the system is not a fully automatic program repair engine; human inspection remains integral to the discovery and generalization of rules (Henkel et al., 2021).
The practical evaluation emphasizes real-world usefulness. The authors submitted 45 pull requests, of which 19 were accepted, for a 42.2% acceptance rate. In a “time-travel” analysis of 102 broken-then-fixed Dockerfiles, Shipwright produced an identical repair in 23 cases, which corresponds to 22.77%, and achieved 98.04% coverage when identical repairs and matching suggestions were counted together. The system’s internal generalization results are also quantified: on clustered broken files, repairs covered 20.34% and suggestions an additional 69.63%; on non-clustered broken files, repairs covered 18.18% and suggestions an additional 46.63%. Across parent clusters, the average coverage of the 13 repair patterns was 84.01%, and across affected clusters it was 68.22%.
A recurrent misconception addressed by these results is that static Dockerfile analyzers are sufficient. The comparison in the paper shows that existing static tools detected possible build-failure-inducing issues in only 20.6% of the examined files for binnacle and 33.8% for Hadolint, whereas Shipwright detected possible issues in 73.25% of the files and additionally provided automated repairs for 18.9%. The contrast is important because many failures arise from external changes—base-image drift, repository evolution, obsolete package names, or dependency mismatch—rather than from purely local syntactic defects.
5. Shipwright as a verification framework for Byzantine liveness
In formal methods, Shipwright is a framework for proving both correctness and liveness of distributed systems in which some participants may be malicious. The framework is organized around executable code written in Dafny and extracted to Go, abstract specifications written as state machines with safety and liveness components, and proofs showing that the implementation refines the specification in a liveness-preserving way. Its top-level theorem for the PBFT prototype is stated as: There exists a modular refinement between our PBFT implementation and our abstract specification (Leung et al., 18 Jul 2025).
The framework introduces three technical mechanisms. First, it uses completion measures for liveness to reduce infinite-trace reasoning to local proof obligations over states and transitions. The key predicate is
which means that for a given task and transition, either the fairness condition already holds or a well-founded measure strictly decreases. Second, it provides a liveness-preserving composition operator that supports both modular decomposition into subprotocols and decomposition into unbounded families of components such as infinite PBFT views. This includes a default-map model for inactive subprotocol instances and synchronous dispatch so that one subprotocol can trigger another immediately. Third, it supports message stapling via authentication decoders, enabling sound reasoning about cryptographic signatures embedded in messages without modeling cryptography at the bit level. The decoder type is given as
1 |
type StapledExtractor<Message, Signature> = Message -> seq<(NodeID, Message, Signature)> |
The executable interface is intentionally minimal. The application provides Zero, Run, and StapledExtractor; events are Timeout, Call, and Receive; and the callback returns a new node state and a sequence of transmissions. The surrounding network model assumes partial synchrony, eventual stabilization, continued clock ticks, eventual timeout delivery, and message delivery by a deadline after stabilization. The framework is therefore designed for settings in which safety alone is insufficient: a decentralized system may avoid inconsistency yet still fail operationally if no administrator exists to restart it after a liveness bug.
6. PBFT case study, detected bugs, and scope of the framework
The main case study is a simplified PBFT protocol that verifies agreement on a single log entry, not a full append-only replicated log. The proof decomposes the implementation into the client request, an infinite map of views, and the message subprotocols within each view. PREPARE and COMMIT reuse the same vote-counting implementation, and REQUEST and PRE-PREPARE are also reused. Liveness of a successful broadcast depends on three stated conditions: the network eventually stabilizes, the timeout grows sufficiently large relative to network delay, and the leader for some view is honest (Leung et al., 18 Jul 2025).
The abstract specification encodes Agreement, Termination, and Validity. Agreement requires all honest nodes with a value to agree on the same value. Termination requires all honest nodes eventually to terminate. Validity states that if the client and first leader are honest, the system is stable, and the request is submitted early enough, then the protocol eventually agrees on the client’s request. The framework’s value is sharpened by the bugs it found in the executable PBFT implementation: wrong-view stapled signatures in NEW-VIEW / VIEW-CHANGE, incorrect certificate counting, a timer started too early, and inconsistent VIEW-CHANGE values. The first of these is especially instructive, because it would not violate safety directly but could prevent a valid view from starting and thereby break liveness permanently.
Implementation scale is also reported. Shipwright itself consists of about 13,357 lines of code, with about 1,351 lines trusted. The PBFT case study is about 31,138 lines of code, of which about 266 lines are trusted. The extracted Go prototype was evaluated both in the common case and in three failure scenarios: temporary dropping of all COMMIT messages in view 0, Byzantine nodes sending incorrect PRE-PREPARE / NEW-VIEW / PREPARE / COMMIT / VIEW-CHANGE messages, and a combined attack involving both message loss and malicious leaders. The reported latencies were roughly 2s, 4s, or 8s depending on the number of views required for recovery, while latency remained close to baseline when there was no network fault.
The framework’s limitations are stated explicitly. The prototype handles only a single log entry, and the top-level theorem does not yet capture client reply messages requiring signed replies to conclude success. The paper also notes that a fully end-to-end liveness theorem for PBFT would require multiple iterations of broadcast, since a malicious first leader can force a NULL outcome in one view and the system should still recover on later entries. These constraints delimit the present scope of Shipwright without diminishing its central claim: liveness verification for an executable PBFT implementation, in the presence of Byzantine participants, partial synchrony, and embedded signatures.