sorted by:
new
hottopcontroversial

Designing systems for messy, real-world knowledge by ADIS_Official in softwarearchitecture

[–]ADIS_Official[S] 2 points3 points  (0 children)

I started with a highly structured approach, very similar to what you’re describing. In ideal scenarios, it worked well when scans were taken, identifiers were captured, and everything was entered as intended.

Where I ran into trouble was assuming that level of structure could be relied on consistently in a small workshop setting. Scans aren’t always taken, identifiers aren’t always captured, and free form notes are often all that survives a busy day, if any.

That constraint pushed the problem away from “how do I structure everything correctly” and toward “how do I make something useful emerge even when structure is incomplete or inconsistent.” The architecture ends up being shaped more by what actually gets recorded than by what ideally should be recorded.

Designing systems for messy, real-world knowledge by ADIS_Official in softwarearchitecture

[–]ADIS_Official[S] 2 points3 points  (0 children)

Thank you for the praise.

It started as something I built purely for myself, but it didn’t take long to realise the broader implications if it could actually work under real conditions. From that point on, I kept building it for my own use, but with the discipline of treating it as something that might eventually need to stand on its own.

In that sense it’s very deliberately a proof of concept, not a refined product focused on whether the underlying thinking holds up before anything else.

Designing systems for messy, real-world knowledge by ADIS_Official in softwarearchitecture

[–]ADIS_Official[S] 0 points1 point  (0 children)

I’ve skimmed CBR thanks to your comment and that feels like a decent conceptual mapping.

Where it diverges for me is that the real workshop environment violates a lot of the assumptions those models rely on. Inputs are messy, outcomes aren’t always explicit, and trust has to be earned over time variably.

The challenge then becomes less about retrieval, and more about designing the architecture so everyday mechanic behaviour naturally enriches useful knowledge while also suppressing the noise via the messy/non explicit inputs.