Elysia Tools
Navigation
Workflow Playbook
Check UUID structure, Semantic Versioning syntax, and URL slug characters with focused evidence, without confusing a valid format with uniqueness, availability, or release compatibility.
Hubs
Collect the exact values that will cross a system boundary: a UUID in a record, a version in package metadata, or a slug in a route. Label each value before validation. A string that resembles a version or identifier can still belong to a different local convention, so the field contract should decide which tool is appropriate.
UUID Validator can expose format and structural observations such as version and variant. SemVer Validator can break a version into major, minor, patch, pre-release, and build metadata. Slug Validator can flag characters, case, and separator choices. These are useful facts, but they do not replace a project policy that may forbid nil UUIDs, reserve a slug, or require a particular release channel.
Save the raw input and the validator output. For a failure, show the grammar issue and propose a correction that the owner can approve; do not silently turn a changed identifier into an accepted one. For a warning, record whether the project accepts it and why. This makes a later QA or release review reproducible.
A passing format result cannot tell you whether a UUID collides, whether a package name or URL is registered, whether a slug resolves, or whether a release is compatible with existing clients. For version impact, continue with api-versioning-breaking-change-review. For route and canonical concerns, consult technical-seo-url-workflows. The smaller validation-format and validation-validate workflows are useful when the review expands beyond these three identifier classes.
Accept the record only when every value has a class, a validator result, and a policy decision. Mark external checks as pending rather than implying they passed. The useful deliverable is a traceable syntax review with clear limits, not a promise of global uniqueness, availability, ownership, URL existence, or publication compatibility.
Workflow playbook
Create a small review table with the raw value, intended class, owning field, and policy source. Route the three classes through the focused validators, while reserving registry, DNS, routing, and compatibility checks for their own systems.
Run each UUID through UUID Validator and retain the format result, detected version, variant, and any nil-UUID indication. Compare those observations with the project policy; a structurally valid UUID is not evidence that no other system uses the same value.
Send the proposed version to SemVer Validator and review the major, minor, patch, pre-release, build metadata, errors, and warnings. Treat the output as syntax evidence only, then use the API versioning and release process for compatibility and change impact.
Run the candidate slug through Slug Validator and record character, case, and separator failures. Before publishing, separately verify route ownership, collisions, redirects, reserved words, and the destination URL; use the technical SEO workflow when those checks are in scope.
Use UUID Validator for hyphenated UUID structure and component analysis, SemVer Validator for x.y.z with optional pre-release and build metadata, and Slug Validator for lowercase URL-safe words separated by hyphens. Do not select a validator merely because the value looks like an identifier.
A pass supports a syntax or convention note for the supplied value. It does not prove that an identifier is globally unique, that a package or URL exists, that a team owns it, or that a version is compatible with a release.