CadSyntra
Back to Case studies

Demonstration study

Layer naming standardization

A small, fully inspectable transformation showing how inputs, rules, decisions, and boundaries can be defined before automation is developed.

Original demonstration

Original demonstration created with a synthetic scenario, names, and data. It does not represent a client, commissioned project, deployed software, or commercial outcome.

Origin
Synthetic scenario and data
Output type
Expected under the stated rules
CAD execution
Not performed

Purpose

Make the rule reviewable before implementation.

The demonstration represents how a normalization routine can be specified and checked. It explains CadSyntra's approach; it does not simulate a professional delivery.

Synthetic context

A deliberately small and inconsistent list.

Five generic layer names were prepared with outer spaces, lower case, underscores, repeated separators, and one discipline alias. No name comes from a third-party drawing or standard.

Represented problem

The same convention appears in different forms.

Without an explicit normalization sequence, review relies on interpretation and exceptions are difficult to discuss. This example limits the problem to the text of each name.

CadSyntra's contribution

The scenario, rules, and evidence were built for this demonstration.

The contribution was to define the problem, create neutral data, order the rules, record decisions, and present the comparison. It did not include automation code, a plugin, a CAD drawing, or deployment.

Defined constraints

What the transformation can and cannot decide.

  • Operate only on the five published synthetic inputs.
  • Apply rules in the stated order without inferring the correct discipline.
  • Use only the ELETRO → ELE alias declared in the example.
  • Treat the output as a reviewable expectation, not the result of executed software.

Approach

Deterministic normalization in five rules.

Each input follows the rules below in order. Every output must be explained by the stated transformations.

  1. R1

    Remove spaces at the beginning and end of the name.

  2. R2

    Convert letters to upper case.

  3. R3

    Replace each underscore with a hyphen.

  4. R4

    Reduce sequences of hyphens to one separator.

  5. R5

    Replace only the ELETRO prefix with the ELE alias.

Inspectable evidence

Input, applied rules, and expected output.

The outputs below were written according to the example rules. They were not produced by a plugin, script, or AutoCAD execution.

  1. 01
    Synthetic input arq_parede
    Applied rulesR1, R2, and R3
    Expected output under the rulesARQ-PAREDE
  2. 02
    Synthetic inputARQ__PORTA
    Applied rulesR3 and R4
    Expected output under the rulesARQ-PORTA
  3. 03
    Synthetic inputeletro-iluminacao
    Applied rulesR2 and R5
    Expected output under the rulesELE-ILUMINACAO
  4. 04
    Synthetic inputhid-agua-fria
    Applied rulesR2
    Expected output under the rulesHID-AGUA-FRIA
  5. 05
    Synthetic inputARQ-PAREDE
    Applied rulesNo change required
    Expected output under the rulesARQ-PAREDE

Technical decisions

Visible, discussable choices.

Fixed order

The sequence prevents an alias or separator from being treated differently across inputs.

Limited vocabulary

Only one known alias is converted; unmapped terms remain available for review.

Qualified output

It is called an expected output because no routine was executed.

Observable result

The comparison is consistent with the stated rules.

Across the five published rows, expected outputs use upper case and a single separator; the ELE alias appears only for the intended input. This demonstrates internal consistency, not automation effectiveness in a real environment.

Limitations

What this material does not demonstrate.

  • Execution in AutoCAD or compatibility with any version.
  • Implementation in .NET, C#, AutoLISP, or another CAD technology.
  • Reading, changing, or validating a drawing.
  • Handling conflicts, duplicates, exceptions, or a team's real standards.
  • Deployment, maintenance, stability, performance, productivity, savings, or error reduction.

Technologies actually used

The published material is a static editorial demonstration.

  • Versioned JSON for data and copy.
  • React Server Component for static rendering.
  • Semantic HTML and Tailwind CSS for responsive presentation.

In a real project, assessment might indicate AutoLISP or .NET with C# to execute rules in AutoCAD. Those technologies were not used in this demonstration.

Relationship with the offer

The evidence is linked to a published capability and problem.

Next step

A similar routine needs rules and boundaries from its real context.

The Contact page shows what information helps describe the current process and preserves the context of this demonstration in the form.

See how to describe a similar routine