if I understand your question I dont understand how bin/hex or assembly are related.
I assume the meat of your question is how do I get from the basic gates, AND, OR, NOT to instructions like move, load, store, add, etc.
I have my own little teaching instruction set I made from scratch that has some of the details of say how an add and subtract work from basic gates and things like that http://github.com/dwelch67/lsasim.
Look for the Code (something something something) book from Petzold. May start way to elementary but walks you slowly from nothing to do with computers and electronics into binary, hex, and into the basic gates, etc.
Are you asking about how you would build one from scratch today, or how did they do it back in the day? Today you would start with a definition of the instruction set. you just sit down and write it out, you think about the types of instructions you must have the loads and stores and moves and alu stuff, and then how many registers, how big the registers, this in part affects the instruction size, you think about the instruction size...
Let me stop and ask you how do you write a program? Starting with a blank screen on a text editor? You have some idea of the task you are trying to solve the variables you might need, the functions, the programming language, etc. And each person is different but to some extent you do a little of this (say defining and writing functions), a little of that (making header files with reusable defines and enums and structs and stuff), and a little of the other thing (just code, fill the functions with variables and code). And you circulate around the different tasks, in the end you feel you have a balance of code size, speed, readability, quality, functionality, etc. No different with hardware design. hardware designers use programming languages (vhdl, verilog) as well and go through the same process, the programming is only slightly different to software, the primary difference is that different lines/modules of hardware programs execute simultaneously where software executes linearly.
Just like coming up with a software program you balance the desires, performance, size, features, etc. You might have some design rules forced on you either that you wanted or that your boss made you do, etc. As with software design well after the initial design into implementation you may find out that you have some big mistakes and have to go back to initial design and change the instruction set, big or small changes. Might get so far as to have a compiler and simulated processor to find you really needed a couple of specific instructions that dramatically improve the quality of the compiled code, performance, etc.
So you have invented some instruction set from scratch, you have used some experience with hardware design to group similar instructions with similar bit patterns so they can be more easily decoded, not just for hardware language programming but it saves on power and gates and all that good stuff. These days you would make some sort of a simulator, my understanding is ARM was a software simulator first then the hardware designs came later, dont know if that is true but sticking with that story. This depends on the team some teams may be just hardware folks and want to just get into programming in the hdl, some like me may want to do a little of both. These days good hardware language simulators are available so you dont have to build any hardware you compile and simulate and do much of your debugging with a hardware simulation program/package. the software team can develop assemblers and compilers for the instruction set and using simulated ram and rom feed programs to the simulated processor and put it through its paces. we have simulated a full linux boot on a processor I worked on not long ago, took many hours but it worked (found a cache bug in the logic that way).
So now for what I really think you were asking. How do you get from basic gates to a processor with an instruction set. Well basic gates AND, OR, NOT are really analog, they dont have a concept of time, you cant instantly change the voltage on the inputs and as you change that voltage the outputs start to change. gates are made of transistors and transistors are amplifiers, take the input multiply it by some number and allow that much current to flow on the other side. when we use them as logic gates we are actually oversaturating them, the input voltage is so high or low that the transistor can only drive max voltage or no voltage (current). basically the transitor is turned into a switch. long story short, there is no concept of time. In order to have an instruction set we have to have instructions happen in order we have to sequence through the program, we have to have a concept of now we are on this instruction, and in the next time slot we will work on that instruction. Just like the game of turning an amplifier into a switch you play similar games with using basic logic gates with a clock. the clocks come from magic crystals in a can (not worth getting into that here) that make voltages that turn on and off at some fixed rate. use that voltage in logic equations and you can start to sequence things.
very very briefly think of this truth table:
0 0 0
0 1 1
1 0 1
1 1 0
0 + 0 = 1
0 + 1 = 1
1 + 0 = 1
1 + 1 = 10 (2 decimal)
focusing on the lsbit only, a one bit adder, the truth table above describes a one bit adder. It also describes an XOR gate. One input is true or the other but not both.
To get more than one bit you have to look at carry bits carry in and carry out and you need a three bit adder two operands and a carry in with two outputs, carry out and the result bit. Once you have that three input two output adder you can cascade that as wide as you want. But this is still analog, the gates change instantly.
How you turn this analog adder into an ADD instruction, is you have some logic that looks at the instruction which is sitting as inputs to these gates you have arranged. some of the bits in the instruction say, this is an add instruction, some of the bits say that one operand is such and such register, maybe register 7, other bits may say the other operand is register 4. and depending on the architecture you might have another register defined in the instruction that says put the result in register 2. Now more logic sees this as I need register 7's contents to be routed to one input of the alu adder and register 4's inputs routed to the adder, and you route the output of the adder to register 2. Since the clock is part of this logic there is a period of time from the beginning of the clock period to the beginning of the next clock period where all the analog signals settle down and resolve the logic equation they are wired to do. Not unlike when you flip a light switch you change the lights state from say off to on. it takes a period of time for that light to warm up and basically get into a steady state. Not much different here.
There is some logic that says things like if this clock period is the execution phase of an AND instruction, then the next clock period I am going to save the result in the output register. at the same time I am going to fetch the next instruction etc. So for modern processors where the alu execution is often just one clock period because the analog logic can resolve the logic equations that fast. Older processors you had to count to some number leave the adder wired up, wait for x number of clock cycles for the adder logic to resolve, then sample the result from the output, feed the alu different inputs, wait x number of clock cycles for that to resolve, repeat forever or until the power goes off.
What do I mean by logic equations? just that, if you want you can think of it in terms of AND, OR, NOT gates. For each input bit to the alu adder circuit there is an equation, likely a very long equation which includes the clock, which includes the flip flops (individual/single memory bits) that contain the current instruction (plus the equations that feed each of those memory bits) and on and on. Take a single software function you have written, in the language you have written it, assuming this is a function that takes the inputs, performs a task and then finishes and returns a result. Think of all the possible combinations of inputs and what the different execution paths are through that function. You may have written it in some high level language but you could probably even in that language rewrite it to be more primitive and more primitive using many nested if-then-else structures. and go lower down into assembly language perhaps. Not unlike the equations I am talking about, the hardware programmer doesnt program in these long winded equations any more than you probably program in long winded if-then-else trees in assembly language when the programming language of choice saves so much of that. Just like the compiler you use turns your small source code into long winded assembly with lots of if-then-elses, there is a compiler that takes the hardware programming language code and turns it into a logic equations. Just like when you take one program written (to be portable) in C and compile it for different instruction sets the assembly and machine code is different, depending on where you plan to build your chip or what programmable chip if you use a cpld or fpga you are using the hardware programmers program resolves to different lists of logic equations based on the logic blocks available from that chip builder or programmable device.
Now going back to the first cpu (which today we would consider a microcontroller but then it was a cpu). You did all of the above on paper, and you didnt use hardware programming languages you actually wrote the logic equations, but you even more carefully chose the bit patterns for the instructions to make the number of gates and the wires to connect those gates as simple as practical. On paper, by hand you had to both create the long list of wired up logic gates and then you had to draw the actual components on a blown up version of the silicon mask. even today chips are done using what is similar to a photographic or silkscreen like process in laymans terms so you would take these blue prints if you will and shrink them then apply them to the silicon layers.
here again back in the day everyone had a better handle on assembly and not only might you end up doing some assembly programming you might not have had a text editor nor an assembler you might have had to write your first programs by hand on paper, then using a reference manual, by hand converted that to machine code, ones and zeros. On some of those computers you might have had to load the ram by flipping switches, flip the address bits, flip the data bits until they match the numbers on your paper, flip the clock bit up then down and you have loaded one memory location with one byte of one instruction of your program, repeat a few hundred times more and hope you make no mistakes.
In the same way that the first lets say C compiler was probably written in some other language then it became self hosting by being re-written in C and compiled by the first C compiler then again by itself. Then the C compilers were used to invent other programming languages which then became self-hosting. We invented operating systems and text editors that built upon themselves, and it is all black magic left for a few folks behind the curtain in the corner to do...
yes, very long winded, it is a big question needing years worth of study and experience to truly grasp. look at my lsasim, I dont claim to be an expert in anything, but it is an instruction set, there is both a simulator that executes the instruction written in C, and another implementation of the processor implemented in a hardware programming language that can be simulated using different tools. Plus a crude assembler and some other tools and such. Perhaps, by examining some of this, in particular the hardware programming language code it might close the gap on what I assume you were asking. If I have not closed that gap or have made a long winded tangent please let me know i will happly remove this answer (assuming I am able to I dont hang out at programmers exchange much).