I'm Dave Ackley. I've spent most of my life in computing, starting with Fortran on punch cards in the 1980s. It was so easy to make a computer do new things. It was great fun and I've just followed my nose from there. In the 80s I did learning algorithms and function optimization. In the 90s it was artificial life and distributed social networks. I've kept one of my worlds going ever since. In the 00s it was biological approaches to computer security and more artificial life. And over the decades, in and out of academia, two thoughts stuck with me. First, that living systems and computer systems are really the same kind of systems. And second, that we've all kind of painted ourselves into a corner by focusing on software efficiency and correctness, while just assuming that hardware is a perfectly reliable world in a box. Because as deployed systems, computers are not perfectly reliable.  It drives me crazy. I'm embarrassed by my field. Now, I talk about that a lot, but today I want to go in a different direction. If we can imagine computing without perfect isolation and repeatability, without deterministic execution, then in the big picture we can take computing ideas, software, programming languages, application program interfaces, APIs, and apply them to understanding people and their interactions. People use language to inform and persuade each other, and I think we should say to program each other. And that's the theme of today's nutjob rant. We are coders. I made a button for it. Now to set some expectations up front. For starters, I've got kind of a lot of moving parts here, and it'll be amazing if they all work. Also sort of sniffling a little bit. And the talk kind of goes all over the place, back and forth between people and manufactured machines, but we're always aimed at implementable processes that can run, at least in principle, on either. We start with a meta-meta big picture view, but we'll have a lot of little specific drive-by examples and a couple little demos too, I promise. And I say there's good code in here that's really got potential.  It's ideas, code for you to judge. And if it makes some sense, maybe you'll want to support or explore it further. So now I'm here and you know the critic. Well, if all there is here is potential, well, it better be funny too. Well, you know, I'll try. We'll see. And one more critic-y thing up front. If I'm doing this right, at some point, you'll probably think, oh, please, that's so obvious. It's just rhetoric, philosophy, delkarnagy, psychology, philandiology, and glib and poorly executed as well. And on the one hand, you know, I'm like, I know, right? When doing science, we're always looking for the unexpected fact. But here we're doing something more like software engineering or API design. And we're looking for the broadest applicability with the least astonishment for the coders using the API. So the goal here is not to be specifically surprising, but universally obvious. Let's see how it goes. One of the great human activities is trying to explain stuff, to paint the big picture. People say it's all about money or it's all just physics. And the variable, the X, can be like anything. Just physics, just business, just luck. All about faith or love or connections. About guts and honor. Usually it's some kind of fancy, jargonic, incantation version of that stuff. And it's always a huge exaggeration. Money really doesn't explain why the sun shines. Physics really doesn't explain why my name is Dave. It's all just X. But not all stuff is X. And some is not just X. So it's all just X. Strictly speaking is four words and two lies. Well done. Of course, the talker says, no, no, it's not lies, let me explain. But you fall for that, then you're stuck there listening as the shining answer to everything melts down into this big mess of exceptions and redefinitions and fine print until all you really know is that sooner or later somebody's going to try to get you to do something. And maybe you do it, maybe you don't. And maybe it's worth it. Maybe it's not. If you do it, you buy it, you own it. It's your call. Which brings us to this. Right now it's we are coders. It's all about code, about programming. That's this X. So officially this is the second of six lectures in the Hyperspace Academy Introduction to Classical Hyperspace course. But the first lecture was seven years ago. So I really need to pick up the pace if we're going to get through this. We'll see. So we are coders, meaning we're all coders. This big picture we're painting with a nerd palette. Code, debug, deploy. But it applies to all of us whenever we speak or communicate. We point directions, we ask for the salt, send a tweet, pass a law. It's all code and we're all coders when we do it. Now the purpose of deploying code on any machine always is to get it to do some work that we want done. We're all coders and we're always on the lookout for machines that could do us profitable, reliable work. Which sounds like it's all about money, but money is just one example. Deploying profitable code can be as simple as look out. Hey, thanks. And here we're using work in a completely mechanical physical sense. Moving salt molecules toward us is work. Tapping a screen is work. Stopping at a light is work. And now Critic says, but that's ridiculous. The real purpose of a code deployment, as you call it, depends on its meaning and our intent and our consciousness and free will and bup, bup, bup, sure, yeah. Always tying code output to some act of physical work. However insignificant is a fantastic oversimplification, but it puts all code on an equal footing. It's a universal solvent for evaluating and comparing code. And that's potentially big. And yeah, saying it's all about profitable, reliable work for us sounds totally selfish and shameful, but we're all experts at running that computation in our mental fortress of solitude. We just don't usually talk about it because we don't see what that would do any useful work for us. So a basic goal of a Hyperspace Academy curriculum is to make this view so thunderingly obvious that it's undeniable to communicate more effectively, to corner hypocrisy, to make things better. Not just for society as a whole, but for us individually too. Unless we're grifters. Now it's clear that code is covering a lot of our canvas here, and we could imagine that real coders might object to the dilution of their jargonic incantations. And we'll touch on some issues like that at the end. But Hyperspace Academy rules, first we go for it. And our starting point is it's up to the coder to make the code work. Now that might seem obvious, but traditionally coder claims they're done when the code is correct. When it does what the client specifically asked for, kind of deal with the devil style, whether deploying the code actually achieves the client's larger goals or not. And that has to be partly right. Coder can't do actual magic. And in the end, clients said whatever they said. But there's usually ways a coder could have done a better job and didn't, but they'll fall back on mere correctness as needed to paper over any bad spots. And typically these days, it's hard to find any clean line between coding and deployment. It's a blur of design, debug, deploy, design. I mean, come on, the whole point. The added value of software is that it can be changed easily. With a button click, a flash of insight, a change of heart. And clients usually can't know exactly what they want. They need to try and see what works. Design, debug, deploy, design. Now for sure, there are exciting moments of great code amplification. When a blockbuster movie or a song or a game comes out when a slogan or a meme goes viral, but we are coders and we say every running of code is a deployment, even the quickest little go while we're debugging. And we say code amplification. Distribution and reproduction is part of code execution. So correct comes way later. We begin with real coders ship code. Which means that shipping decisions and even machine maintenance are partly coder responsibilities. When all your automation fails and it will, you personally have to answer the beeper for your machines or it's on you for not caring. And that's a drag but it's fundamental. You can wish or you can whine or you can be a total jerk but it's up to the coder to make the code work. Now, critics like, you know, well, so what? Truck drivers or oil painters could say the same. We are painters, we ship art. Truckers ship everything. And then we're like, yeah, sure, sure, big picture. But we are coders, has some neat features too. For example, I can prove to you kinda we are coders because what is we? Well, for starters, it's you and me. And we're pretty sure of two things you and I. First, I'm a coder shipping code. This code right now. And second, you're interpreting this code somehow.  Q-E-D, kinda. And even though those two nows, mine and yours, are nowhere near each other in space and time, they're both absolutely legitimate because code can be handled two ways, as data I'm shipping or as program you're interpreting. But the code itself is the same either way. So we're really better off centering the view on the code. Yes, at one end there's a coder at the other a machine, but those roles are fluid. The code's the fixed point. The most real thing about this interaction we're having here. Us coders. Can you feel it? Now, critics like, yeah, whatever. But about that machine thing. Machines are so limited and rigid and bloodless, not lively at all, not like real life, not like me. And we're like, yeah, but that's because simple machines are limited. And even programmable computers traditionally were based on deterministic execution, that perfect repeatability that doesn't actually exist for real-world systems. So we have to accept that machines can inevitably do something bad, but we can also design them to surprise us with something good, which we'll talk about in a minute. And when we do that, we're heading for a world where machines may not just solve problems but set them and have initiative, creativity, passion, all of it. Which is good, because we're trying to run code on each other, which means we're not always the coder. Sometimes we're the machine. So an obvious question is, what kind of machines are we? Or backing up, where should we even look to figure out what kind of machines we are? These days, it's trendy to ask neuroscientists why we are the way we are. My neurons made me do it. Or my whole brain. Or it's about evolution. And answers like that have germs of truth, but they also really kind of miss the point. When asking how a programmable machine will behave, you don't focus on its silicon chips and its voltage rails. You look at its software. For sure, neurons and brains have their little tricks and their special quirks, and we need to understand them because they're part of our hardware. But we already know they're hugely adaptable and modifiable. They're programmable. By external code, we can transmit if we can figure out a way to express it in a form the machine will interpret. What we coders care about is what can the machine do? What kind of actions can it perform? And what's the dictionary that will allow us to create code that will trigger and orchestrate those actions towards reliable profit for us? So instead of looking at the brain or physics or history, we're better off looking at the code people run. That could mean look at structural coding details or turns of phrase or images or symbols that might evoke particular responses. What coders want to understand are the virtual machines, the programming language interpreters, that people can run if a piece of code appeals to them. But where do the dictionaries and the virtual machines come from? Can we fork an existing code base and modify it for our own purposes? Well, if we just need a secret code for our club, that's no problem. But it's harder if we want our code to run on more than a treehouse of machines. After all, most available machines are already doing all sorts of profitable, reliable work. And if running more of our code means running less of some other code, sooner or later there'll be coders pushing back at us, like in academia. It's packed with people squabbling over disciplinary boundaries and proper meaning of jargon. A fundamental part of making code work is dictionary maintenance, which, yeah, sometimes feels like, but hey, you look at mass media and much of what you're seeing is dictionary and machine maintenance. Incessant advertising, competitive reframing, gatekeeping, all of it. So achieving wide distribution of significant new code is hard. But however much the entrenched coders hope we forget it, software is soft. So as long as there's smoldering embers out there somewhere, a code wildfire could break out if conditions became right. And if it does, the deployed code base can shift like that.   They're cleaning up the code base, and that gets big respect from me. All right, so there's lots of ways to view the basic pieces of a programmable machine. One take is this nerd-famous title by Nicholas Wirt, Algorithms plus data structures equals programs. An algorithm is steps to perform over time. A data structure is information laid out in space. Put them together, you're computing. Ubernerd Don Knuth views programming as an art, like writing cooking recipes. Knuth does a lot of math, but it's hard not to like a book that opens by comparing coding to poetry and music. And I'm okay with these approaches as far as they go, but after five decades in computing, to me they all feel kind of wrong for understanding people machines and future manufactured machines. It seems to me there's four key processes. Input and output are obviously essential, although they're both completely marginalized by the traditional perspectives. Sequence is the process of orchestrating internal changes over time, so that we can generate different states at different moments in the same place. It's very powerful. And judge is the process of evaluating the desirability of some internal state of affairs. And that's really the missing elephant in the traditional deterministic computing. Input, sequence, judge, output. They don't have to happen in that order. The real power of our machine is that the programming can, to some degree, configure all four pieces to control each other in various ways. Like we can implement a search process using sequence to judge, to generate possible states and judge to evaluate their quality, as covered in a pre-rec video for this lecture. Of course, people write search algorithms in deterministic machines for deterministic machines too, but when everything is 100% controlled from the top, there's no need for any on-the-spot decision-making. And in fact, deterministic computer coders end up using pseudo-random numbers to make their deterministic code less predictable, as discussed in another pre-rec video. But judge really starts to shine when we finally accept that determinism fails and we're really not the masters of the universe. When what actually happens is not necessarily what was planned, then what's being judged is not pseudo at all. It's the real world. So organizing code around searching is hugely important because that's what opens up space for our machines to create knowledge, display creativity, and surprise us with their results. Now, critics all up with, well, I get we need input sequence output. That's just traditional computing. But judge isn't that important considering we can implement whatever judging we need ourselves. Like you just said, search. We use universal computers, you know. Here, let me Google Turing completeness for you. Yeah, thanks. Very thoughtful. Except for machines in the real world, beyond the cozy prison walls of determinism, we really can't implement all the needed judging. Stuff is always happening in the moment on the spot that each machine has to take care of itself. We deploy code on the judge process because it's there and it's powerful, but it isn't solely or even mostly there for our grubby little search problems. It's really more about dodging things, sizing up strangers, and picking up 20s on the street. More generally, search is just one kind of behavior we can implement. There's lots of other dynamics we could create by cross-connecting the four processes in different ways. It's a plenty powerful machine. And to help with dictionary maintenance, I wanted to boil it down to the simplest, most memorable thing I could. I started playing with arrows. Input arrow, output arrow, up and down for sequence, a loop for judge and a loop for sequence. And eventually I packed them all together and I made this symbol. Whoops. There we go. Which I call the self-image. What do you think? It's a cartoon icon, a reminder of the key processes of the machine we're coding for. Oh, I've got one here. So here's one that I printed up on my little printer. Input, output, sequence, judge good, judge bad. I've been living with it a few months and I like it. It's fun to try to map real-world stuff onto the basic self-image processes. I even made an animated one using some colored LEDs I had lying around to help suggest the range of behaviors we could implement on the machine. I made a switch panel to control it and I've got it set up here with the self-image in a dark box to help keep it from getting washed out by all these lights. Those LEDs are bright, but I've got them turned way down so that I can run the whole thing on just USB power. Now, I'm not a very accomplished self-images and the switches I bought are way too stiff. But just to get the idea, let's try playing a few behavior etudes on the self-image. All right, so here we are down here now. Now, the first thing that we can see is it's doing stuff, it's dark for the moment, but it's doing stuff even though we're not asking for anything and that's representing the idea that the machine has its own business. It's not 100% sitting there waiting for our business. We have to convince it to do what we want. All right, so what's the most simple thing I can think of is something that just does a repetitive output, doesn't depend on any input, doesn't have any internal sequences, so it's something like a lawn sprinkler. Anybody has any lawns anymore? One step up from that could be something like stimulus response. Here's an input, makes an output. Here's an input, makes an output. We could step up to traditional computing, take some input and do nothing else, then do some sequencing. We'd probably do that really fast because we're a computer and do nothing else. And when we're done, provide output and do nothing else. There's the observer looking and thinking, the kid in the corner doesn't say much, watching everything, or on the other hand, there's the motor mouth. Can't stop them, they just go and go and go. Now we can get the judgment mechanisms in here. We could do like a search process. So there'd be like some kind of input telling us what we're looking for, what kind of threshold of quality we want and what we have is not good enough. So we use the sequence to generate new variations and we evaluate them. They're bad, they're bad, they're bad. If we're lucky, eventually we find one that's good and we can send the output. We've solved the problem.  Now one thing about it is, I called this stimulus response, but these things are all completely ambiguous. There's many things that could look like this. For example, when you're in a flow state and everything's just working out great, it could be, so you're taking input, you're getting the correct answer and everything's wonderful. It's like Michael Jordan in his best days. And maybe every once in a while you sort of have just a little thought just kind of pokes through and then goes away, that kind of thing. So what else? We've got the daydreamer. Not paying attention to any input, not actually doing anything, just thinking, thinking, thinking and loving it, loving it, loving it, like that. Or similarly, the depressed person, not doing anything, just thinking, thinking it's all terrible, input happens, it just makes stuff worse. So you get the idea. Let's do one more. This is a long one. I don't know whether I can really get. Let's do advertising. So it's like, don't you hate it when you see this, but if you do this, you'll see this and you'll be happy. If you do this, you'll see this and you'll be happy like that. Now, actually, the Self Image has some features that we haven't really used before. And the main one is that this flowing stuff here like this, this is when we're paying attention to the input, the flowing and the sequencing, we're doing it. But in the advertising, that key step, if you do this, that's a program that's trying to tell you to do a new thing. That's code aiming at the do. So we can say it by, if we do the other direction here, it would be, you know, don't you hate it when you see this, but if you do this, can we see that? Like that. The whole bar blinks, meaning we're programming that. Then you'll see this and you'll be happy. And now the do is different. You can reprogram it, it's flashing, and now it's a new kind of do. And we can do the same thing. We can reprogram, you know, say, well, it doesn't go the way you think it goes. You know, this is what actually is going to come next.   But then it's like, oh, energy and matter are actually equivalent. And it's like, oh, that's new code. And now one sees the world differently. You can even reinterpret what good and bad means, which is really kind of weird. And it's like, you know, okay, now this is what bad is, and this is what good is. And, you know, so we change our fundamental view of how to evaluate stuff that's good and stuff that's bad. That's very weird. Now, unfortunately, if we do the Vulcan death grip on the controller here, did I get it? Yeah, I got it. So we can restore it back. It's harder on real people machines. Okay, that's about it. So, you know, I've got the 3D files and stuff for this. They're all a big mess because I was in a rush like I always am. But I'm happy for good spirited folks if they want to make their own self symbols animated or not, that would be great. Okay, so that was our demo. And, right. So the self image focuses on the machine's processes. And I think that's the right place to start, especially as affirmative action for input and output. But notice how there's nothing in the center. Where does the input go to? What does the sequence read and then modify? Now, we'd like to say the answer is it depends. It could be neurons in there or silicon or biocomputing goo, but we can't just stop there. Like the nerds at the Internet Engineering Task Force, the gold standard is running code. So if asked, at the very least, we have to be able to sketch a plausible implementation of our code or GTFO. And that's where we re-enter hyperspace. In lecture one of this series, we started out by making low dimensional graphs and then we struggled trying to make higher dimensional graphs and finally we switched to predicates, which are amount to a set of yes or no questions that whatever we like as long as we choose to implement them. We arranged the resulting zeros and ones in a bit vector as a point in some high dimensional space, which we called a hyperspace fix, and that's where we left off. Now, in the hill climbing video that's mentioned earlier, we also ended up with a bit vector, which we searched using various hill climbing algorithms, and that's our plan here too. So in the middle of our running self-image, we have some implementation of a hyperspace, which could be something exotic like a neural net, but to keep it simple here, we'll just say it's a chunk of RAM, some conventional memory. And now we ask for a leap of faith. We claim that we can implement suitable predicates for all the machine processes we care about, sensory and kinesthetic inputs, energy levels and joint motor angles and forces and so on, plus lots and lots of soft predicates that we can configure by code. And in particular, we postulate a bunch of soft circuitry between the self-image processes that we can use to configure different conditions and trigger different operations. And to say all that, this is kind of like a coder parlor game. When we're presenting our proposed implementation, anybody can call technical debt about anything we postulate. And if they do, then we're obligated to stop and unpack that part of our story into some simpler physical processes. And if we can't, then we GTFO. Yeah, yeah. And so then if there's rough consensus that the implementation was plausibly refined as the challenger demanded, then we can, if we wish, create the challenger to explain what part of our refined implementation they didn't already see or they GTFO. Yeah, that's a great game. Implementation or GTFO. Anyway, you get the idea. So here, the virtual machine we implement, we call hyperspace search and sequence limited. So let's go play in hyperspace. All right. So if I can get this right here. All right, there it is. Now, if I did get it right, that's the same bit vector we ended lecture one on. And it's Big Jim. And how do we know that? Well, we can check any of the... So it's not... So the first predicate was is it's hot and Big Jim is not that hot. Does Dave eat a lot of them? Yes, he does. Red is not the best color for a Big Jim. It's not expensive and so on and so forth. Yes, they're big size. And yes, they're good on burgers and so forth. So that's the idea. You have zillions of predicates. Here we have 20. And you get answers for all of them. And that is the representation.  Good on a burger. I can say no, it's not good on a burger. But then as far as my little demonstration is going here, it's not a Big Jim anymore. And... But okay, so we can reset it back. And now here's the point. That's just a hyperspace fix. One point. There's really not much to do with it. But if we start getting other ones up here, like if we get Habanero up here, which you can see, it's similar to Big Jim, but it's different here because it is quite spicy. It's different here because red is the best color. Well, if it's a dried one anyway. And so forth. And they differ here. Right. Habanero is not very big and so on. Like that. So now the idea is when you have two things, when someone says Big Jim is the best, someone else says Habaneros are the best, whatever it is. Or someone says, I'm thinking about Habaneros. You should think about a Big Jim. You can generate the hyperspace spanned by them. Which just means wherever they agree on 1 or 0, then the hyperspace is fixed at 1 or 0 on that dimension. And wherever they disagree, you get a wild card. So here it is. They disagree that Dave eats a lot of them. But they disagree on whether they're spicy or not. They disagree on the best color. They disagree about whether they're good on burgers. I don't know. Maybe I think Habaneros might be a little bit intense for a burger. And they disagree on what's this down here. On having a skinny shape. So wherever they differ, we get a wild card. And the volume of the hyperspace is exponential in the number of stars. The number of stars in the hyperspace doubles the volume every time you add another star. So here we've got 5, 1, 2, 3, 4, 5 stars in the hypersubspace. Which means the hypersubspace volume is 32. 2 to the 5 is 32. And that's the idea. And the cool thing is, right, we can take, we could imagine that one of the vectors in a hypersubspace generator is like what we're thinking. It's where we're at. And the other vector in a hypersubspace generator could be code that we receive. And we somehow have to interpret that code and that's part of our leap of faith. But once we've done that and we get it down to these two, we can form the hypersubspace between them and boom, now we have a place to search. We don't want to bother checking things that, what is this, that aren't good on pizza. Because everybody agrees being good on pizza is good. We don't want to talk about things that aren't good building materials because everybody agrees, bad building, we're not interested in good building materials and so on. So the thing is, the more similar the two generating vectors are, the smaller the hypersubspace volume. Or conversely, the more different they are, the bigger it is. So for example, if we have a big gym and someone wants to talk to us about drywall, well, they differ in a lot of ways. They disagree about whether Dave eats a lot of them. They disagree about, I don't know, whether they're good building materials. Yeah, sure, whether they're bigger than a bread box, whether they're made out of minerals and so on. And in this case, we've only got 8,000 different possibilities, which doesn't sound like that much, but we've only got 20 bits here. So if we come up with the perfect anti-drywall concept, oops, when did that one go? There we go. Which one am I missing? There. We've got drywall and anti-drywall, whatever that actually is. And the hypersubspace volume spanned by those two vectors is a million sites. The hypersubspace is full of stars. So that's the thing that they'd be thinking about. When we're talking about people telling us stuff and we're doing stuff or we're just thinking, a fundamental question always is, how big is your hypersubspace? This whole thing, these 20 dimensions, might be a hypersubspace of our million-billion dimensional bigger hyperspace that's really in the center of the self-image. And as you can see, the hypersubspace can be formed by just generating between any two-bit vectors. And as we search or add more bit vectors or stuff, it can collapse. This one, we exploded it. So now we have absolutely no constraint at all. If we ask, what is in the subspace between drywall and anti-drywall, the answer is everything. It really doesn't help. But between Big Jim and drywall, there's many more between Big Jim and Habanero. We could plausibly want to consider any combination of 1s and 0s for the stars. And it might be something relevant. It might be an actual plausible kind of chili pepper. That's the subspace idea. Okay. So fixes to subspaces. Oh, yeah, hill climbing. Right. So now that we have a subspace, what are we going to do with it? We were saying the idea was that the self-image has the ability to be programmed to do search algorithms. Hypersubspace search is one of its entitled things. So let's, I've got another demo here. Yeah. All right. So now I think I've got the same vector here. The Big Jim 01, 01, 111, 01, and so forth. We can flip bits here as well. Same as we did before. Now you'd think if there was really going to be zillions and billions of bits, that putting them all in one big long straight line is really not the best way to do it. But the reason we want to do it here is so that we can use the other dimension to represent quality, judgment, evaluation. So that's what we're going to do. We've got a ruler. So now the height that the whole thing is at is an indication of how good it is. Now we got to watch out. I'm not sure why I did this, but the numbers in the evaluation increase going down. So if we're looking for high numbers, which in this case we are, it's actually going to be moving down when we do it. Now in this case, when we actually flip bits here, nothing actually happens because we don't have a function to try to optimize yet, but we can get one like that. Okay. And this is bitmatch. That's just says for each of the 20 bits, there's a secret target bit, which is the preferred value of it. And if you get the preferred value, you get more points than if you don't. So, you know, the first bit, if I flip the first bit, ah, it made it better. I flip the second bit, it makes it worse. I'll flip it back and so forth. Now, in this case, I happen to know that the best state is all ones. So if I go there, all right, then we achieve a score of 20 because we got one point for each bit that we matched. But we can randomize the target, ah, something like this, and now it's not all ones that we're looking for. So yeah, turning that on made it worse. Turning this on made it better, better, better, better, better, better, worse, and so forth. Now, what we want to do is start automating this. Clicking it gets old quick enough. The first thing we can do is say, which ones were worth picking? Do we want to go down? So we can do this, and now what we get is a picture of the lay of the landscape around a given hyperspace fix. What we're seeing here is, you know, if we just flipped this first bit, the score would go up to 12. If we did the same for the next one, it would go up to 12. If we did these, it would all go up to 12. If we did this one, it would go down a little bit. So that's good. So we could flip that, and so forth. And so here, now we can just pick out the downhill ones right away. Whoops. No, I got that. And there we are. Do we get it? I think we got it. Right. So this bitmatch is so simple. Now, we've got a related one, weighted bits, which is just the same as bitmatch, but instead of scoring one point for getting it right, there's some particular little weight that might be, you know, not one or zero by a half or whatever. So we get a little bit more structure around, well, it's going way up there, around the landscape. Stuff goes down, stuff goes up. This thing hardly changes it at all. It changes a little teeny bit, and so forth. Now, but we want to optimize this. We don't want to do it ourselves. So we've got a bunch of hill climbing algorithms that we can play with. The first one, next to scent hill climbing, it means just go through the bits in order and every time you find one that you can flip and get better, just take it and then move on. And here we go. And now we can see the whole landscape is going up because we have minimized the function, minimized the error, maximized function, however we want to think about it. We scramble it again, and next to scent just again, marches right on through. And it works fine. We can change the target. It'll do it. Everything's good. Now, what else do we have here? Oh yeah, let's go on to the next function. This one's called linear plus even parity, and this one's a lot tougher. And so it's basically the same as weighted bits. For each one, there's a target, and you get a score for matching the target. But there's an additional constraint that across the entire bit factor, you have to have an even number of one bits. And if you don't, if you have an odd number of one bits, you get a big penalty. And as a result, once you're in a place which is an even number of one bits, which this one ought to be, everything looks bad. Everything looks uphill. If we scramble it, look at that. We're way up at zero and there's nothing to do because everything looks uphill. Now let's turn next to scent off. So if I by hand turn this thing, I flip one of those bits that was an uphill move, and now we're way up at, you know, whatever that is, minus two or three or something. And now look at this. Now all of the moves look good, which seems nice, except not all of those moves are actually going to lead to the solution. Not actually going to lead to the best spot. You know, maybe if we pick the one that's most down, we'll be able to do better and so on. So parody is an example of a high order constraint. It depends on the values of all the bits in the system. And in a way, just the essence of computation, the essence of going from ideas and concepts and high level stuff, you know, ineffable beauty of free will and consciousness is taking high order concepts that depend on many things on lots of brain, lots of world, lots of people in lots of worlds, all of that stuff and figuring out ways to implement, meaning breaking it down to lower and lower order problems until eventually we can actually get to stuff that we can solve and put the pieces back together. So parody is essentially hard. But if we move on to, well, there's randomness and hill climbing, talk about that in a sec. But if we move on to stochastic hill climbing, stochastic hill climbing, we've talked about it in the prerec video. It's willing to go uphill sometimes. It prefers going downhill, but it'll sometimes go uphill. And, you know, it still has a tough time with linear plus even parody because it doesn't really want to go uphill. Let's speed it up. But if we give it enough chances, it'll pick one and it'll go uphill and then it has to get lucky and pick one of those downhill moves or actually the one that's on the path to the best solution. And let's see, let's reset this to a known place. I think that will work. Yeah, okay. Now I think we'll have it. We may be able to actually see it if stochastic hill climbing actually gets there. Okay, yep, yep, yeah. All right, there you did it. And then it blew it because that's what stochastic hill climbing does as discussed in the other video. Okay, we'll look at like just a couple more quick ones then we'll move on. So here's plateaus. The idea of plateaus is we take the 20 bits and we break them up into five groups of 4 bits each in order. Let's just let somebody search it. So random a sand hill climbing, we haven't seen it before. It's the same as next to sand hill climbing except instead of four bits in order. It's just, well, we'll do next to sand. And so now each group, so you see the first group of four altogether, the last two groups of four altogether, but we have two groups in the middle that we haven't gotten to be all ones and all zeroes. So each of those groups of four bits is a plateau and by getting them solved and the trick is until you get all four bits in a group correct, the score is zero for that plateau. So you get no signal about which direction to go and next to sand hill climbing as a result just keeps flipping pairs of bits and then flipping pairs of bits and making no progress. But if we take random a sand hill climbing where we might come around and break the order that we consider things, it will eventually figure out just by blind luck to how to make each plateau get all one type and actually solve it. And it just got the next to the last group, third group there, now it's only got one left if we speed it up a little bit, oops, I turned it off, if we speed it up a little bit there it is, random ascent hill climbing did the job. And so plateaus is an example of an intermediate order function. It's four bits, four bits, four bits, but then those groups of four bits contribute independently so you can solve each plateau without considering the other plateaus unlike parity where we had to look at the whole thing. Alright, we'll make it even worse actually to save a little time we're going to skip that, what the heck, we'll do it. So traps is like plateaus except each individual plateau instead of it being zero when you get the answer wrong, there's actually a uphill path away from the good solution. So where these things are going to tend to end up is with one bit on and the other three bits off in each group, that's what we've got that's the highest thing you can get unless you flip all of them off and then you get an even bigger score so this is what they call in genetic algorithms a deceptive function because the uphill direction actually points away from the goal and then all of a sudden there's a very steep cliff when you make that last correct move but you have to go downhill, downhill, downhill and then boom big uphill or the reverse in this case. And again stochastic hill climbing will make more progress here but again it's the same thing, it's getting fooled as well so it has to get a combination of lucky uphill move, lucky uphill move, lucky uphill move and only then can it actually find the downhill move. So it's got two groups now that it's managed to find against the traps, three, four groups, lost one and so forth. So the idea is the course of any given search and now we imagine this being much more complicated and much more subtle combinations of linear portions and higher order portions of a function that we have really no idea how it's all going to come together and we're going to have to there we go great job, let's stop it's too late, stop stochastic hill climbing before it loses it so one way that we can try to solve hard problems is by getting lots of machines to work on it and here's the trick well here's our last one, it's called needle in a haystack and this particular one is all of the million states except one score zero and that one in a million state the needle in the haystack scores I don't know 10 points or something like that and you know we can do anything we want here we can flip any pattern but literally we have to hit a one in a million shot in order to optimize this function and we're not going to do it we're simply not but if we had information from the outside world if somebody else had solved this I mean if we have billions of people and we're all trying to solve a needle in a haystack there's only a million possibilities of billion people will find it quite easily if they can communicate with each other and send code saying you know here look in this area where the light is good we can do much better so we have a similar example we can there if someone can tell us that look in this hypersubspace so now we've got slashes through some bits saying they're fixed we've collapsed the hyperspace down to a much smaller hypersubspace how do we know all the fixed bits should be black instead of some of them white because people figured out the accumulated knowledge of mankind and now whoops that does happen I don't really know why that happens it's a bug in my stuff there we go so we managed to optimize it and we randomize it again and it should be quite quick to actually finally figure it out because this is only a three dimensional subspace so it's not there it is now on the other hand if we have a hypersubspace that's wrong so now we've got a bit that's fixed one we're never going to get it at all we can spend we can spend all our time in our hypersubspace and fail and fail and fail and fail and this kind of reminds us of depressed person that they seem to be trapped in a subspace they work and work and work and everything looks terrible and we figure maybe what's going on that's because once again I've got a bug in my code that allows us to flip bits that aren't supposed to be flipped we'll make more of them there we go oh and look at that did it again alright let's let it go alright so that's what's in the center of the self image hypersubspace search and sequence processor and sequence is you know just when we're supposed to do something when we get the result because we're going to have to take this code and it's coming in and it's expressed in kind of linear form like language and we're going to have to parse it using an interpreter and all that stuff so we're going to be doing direct sequencing not just searching all the time alright so winding up I'm starting to lose my voice here too it's going pretty well actually so far obvious waste I mean you know we've talked to the critics I'm going on through there's nothing new here that's the easiest attack I can think of or it failed to cite Heidegger you name it and that's really true so aside from the anticipated objections that I gave to the critic going along there's plenty of other things to complain about and again nothing new here well kind of it's supposed to be because not specifically surprising but conversely obvious and you know writing science papers it's really all about the related work so I'm always full of shame when I don't have good related work but you know the truth is I really did sort of follow my nose for all of this kind of stuff and then only when I was actually writing a paper I would go back and find related work for all this stuff which is why it seems so creative and poorly expressed sometimes just so stories there's criticisms that descriptive language are so general that it applies to everything and therefore it tells you nothing about anything and that's always a risk but I think we have an edge with we are coders because again of implementation or GTFO just because we can just use computation to describe a tremendous amount of stuff it doesn't mean everything is well described as a machine as a self image and so forth it's not necessarily true the point is that computation is where you find it and that may take you know insight cleverness wit to figure out how you could put a bit of code together that would get that machine to do profitable reliable work for you so it's you know not this the magic just turn the crank and get it it requires additional application but it doesn't apply to everything so I think we escape the just so story criticism and again mainly because implementation or GTFO that the whole process is we can talk we can talk but it's all an IOU until and unless we can reduce it to implementation reduce it to lower order and finally your feeble skills are no match for the power of determinism that's the one that's actually the thing I'm most worried about that you know I spent a lot of time in deterministic execution and it's really addictive you get that you know it will do whatever you say it'll do it really fast and it's really fun and to step beyond that and say no actually you know let's let's do deploy something super simple and deploy a whole bunch of copies of it in fact let's fill the machine with as many copies of it as we can so that we'll have a whole army heading towards the answer to this simple problem like that and say wow okay we'll actually get it to work but we're just doing a simple problem the addiction the risk of deterministic computing is that it makes us feel like we should expect to be able to kind results that we get when we focus on correctness and efficiency only and leave ourselves wide open brittle as a piece of glass against dealing at anything unexpected alright so we're reaching the end coming to the end of this go we are coders it's about living computation and taking an expansive view of code where we abandon any notion of deterministic execution allowing us to repurpose computing concepts born and raised in an utterly centralized and micromanaged tyranny and apply them to fallible malleable gullible people and other living machineries we are the coders of our lives and of our shared reality and we each have to turn profit enough to stay alive through the next squeeze and we are machines long evolved to do that and we all fail in the end of course this is all just a starting point like truth for example has hardly come up our machines are material systems in the material world and much of their processing is direct result of their material form at the bottom it's like reflexes direct connections from input to output sense act above that there's systems for handling trouble with input filters to highlight risky stuff custom outputs for emergency response and sequence machinery always trying to predict all that hardware and processing I call direct reality and most of it is not programmable by the coder at least not directly it's not that it's fixed like a reflex but it programs itself or at least it tunes itself based only on the machine's own actual experiences and then above that grounding out in direct reality but separate from it there's the virtual machine processes the programming languages interpreters and the code sequence storage mechanisms that make the machine so flexible and powerful and built atop all of that starting with code like but leaping vastly beyond it there is consensus truth a huge interlocking code base a work in progress yes but already the absolute glory of humankind about how to see predict judge do most effectively Keith said truth is beauty but coder says until implement until a beauty implementation is unpacked so in the meantime we say truth is reliable practical code practical jokers go for quick laughs by violating the consensus truth API tricking machines into seeing incorrectly and then unprofitable work haha of course the pranksters commit credibility suicide in the process the API has some defenses against such things grifters do it too and it's a real problem but still at any moment there is a vast flux of sincere consensus truth code moving through our communication systems large and small which does raise an issue as a basic part of machine maintenance coder typically needs to assess how well their deployed population of machines is holding up they'd like to have some kind of message that each code deployment could send to signal that it's still running but what message if it's anything compatible with consensus truth 2 plus 2 equals 4 then how is coder to know that that's really from an active installation and not just a random moving fact so there's a standard trick coder selects some deliberate error and has the machine ship that this chosen error can be anything that's unlikely to be mistaken for consensus truth from non words to strange phrases to funny hats to bald face lies and counting traffic in any particular chosen error allows not just the coder but the whole population of installations to assess their own numbers one final thought we'll write better code and get more profitable reliable work out of our deployed people machines if we understand their common failure modes for starters people machines are powerful amplifiers both from their own input to their own output and also from their output to other inputs and amplifiers are touchy they can feedback overload burn out damage nearby stuff it's great when our machines are zooming along working steadily but we need to recognize when the machine's heading the wrong way or are stuck looping without progress now I'm old and I'm doing alright now but I remember a machine getting hung up in depressed person can be in profound pain and the hell of it is machines that are hung up on something stuck on a contradiction are actually the most open to running new code they're looking for it their existing stuff isn't working the consensus truth database is a magnificent achievement but all too often it can be dismissive and arrogant religions have desperation APIs just for this purpose cult leaders and grifters do too I think that the hyper subspace of consensus truth has plenty of room for empathetic AIs empathetic APIs to help stuck machines get moving we should develop empathetic APIs that are still tightly coupled to direct reality and consensus truth but offer place and purpose and positive meaning if it's all just physics I don't know exactly how to implement that but we are coders I know we should do it we should do it in the words of the master for every hung up person in the whole wide universe thanks for watching


So if I could ask everyone to join me with your, ideally with your videos on, certainly at least your microphone's on. So welcoming back Andrew Josie, welcoming live Chris Ford, welcoming back Sonya, Vishal, Chris Frost, welcoming live Jean-Baptiste I hope, and Mark you're already there. So this is the Ask the Experts panel. This has always been a popular session when we've done face to face events, live events. It really does give people an opportunity to share their questions or experiences with people who are very familiar with the standards and instrumental in creating them in some cases and evolving them in others. So that's quite a gallery I can see across my screen. Thank you all for joining and we'll kick off to keep a bit of flow going. Mark, I'm going to come to you first. Question came in. Mark, you talk about architectural debt. Can you explain that a bit more please? Yeah, it's derived from the notion of technical debt. The idea is that often if you're pressured as a developer or as an architect, because something needs to go live in the short term because there's an immediate business need, then it could be that you take some corners, you take shortcuts knowing that you don't have the ideal solution, but you know that you need to fix that later. That's basically a debt you have to basically to account for and later on you have to repay that debt. That's the idea. That could be in the technical solution and technical debt. That's mainly for software developers with architectural debt is the same idea. You made a choice that doesn't really fit in architecture knowing that you're going to repay that debt later on, but if you don't record that debt, and that was what I mentioned that you can use your models for that, if you don't record it, it must stay in your architecture. If you don't fix these issues later on, basically you will end up in an architecture that is a kind of trans-work of all kinds of short-term solutions while having an architecture anymore, I would say. So that's the idea. All right, thank you. I think that's clear. Jean Baptiste, welcome. Exciting day with the launch of the community. So thank you for your help with that. Question came in. Are there some questions saying, great, I have a place, well, comments. I have a place to ask my dumb questions now, which is good. And a few others, people welcoming the initiative. The question came in. Are there actually already some models that are in the repository on the community site yet, or will they be coming soon? They will mostly come soon. I have already shared one of my models and some people from the already in the community, like Nicolas Figue, already shared some things. And we are in the process of moving things around and appropriating this. And we try to have more food for people for the end of the year. Great. OK, thank you. This question, I think, is probably going to come to you, Chris, and maybe Sonia, between you. It's a question that came in earlier today around, well, it was a statement. My organization is not a member of the open group. Is there a way of getting involved in open group activities or community activities in some way, other than being a member? Obviously, one answer is become a member for the organization. But that may take a while and be difficult in some cases. But any suggestions there? I'm looking at you. You're on me. No, you're not. There you go. OK. So, yeah, clearly the typical path is by membership. But we do have opportunities for folks to contribute ideas via the white paper path. That is, if you have a topic that you believe is of industry significance, then you can submit a proposal to us to put in place a white paper around that context. Generally, the open group treats white papers as opinion pieces rather than components of the standards necessarily. That is one way to contribute. Also, if we're engaging in an area where we need a kind of a broader engagement, we will also offer an invited expert status to some individuals for a particular set of expertise that we need to pull in. And those are the typical paths we have in our members. Right. And there was a part of that same question, which I didn't ask you. But was, you know, is there a way of getting a discounted rate for attendance at events and things like that? And one I'm aware of. Well, I'll let you answer the question. Yes, I'm chomping at the bit to answer that question. The typical discount you can get is through your membership with the Association of Enterprise Architects. Membership in that organization for individuals runs from $75 for a year to three years for $145, not to be too mercenary about it. But that also gets you access to the journal and discounts to not only open group events, but other events too around the Enterprise Architecture community. So that's another path. OK, thank you. Sonya, I think I'll come to you on this one. We are users of the TOGO framework in my organization, but we are increasingly adopting agile methods. Does the open group have any advice on how these two can be combined? OK, excellent question. And actually, a response is yes. There's work in progress into the architect to phone that was back to release soon. A couple of guides about how the TOGO standard can be used along with agile and supporting Enterprise Agility. And besides that, we have several resources in the TOGO library about agile. White papers, we have a very good white paper about agility and webinars, blogs and also other publications about agile. So you can go into the library and make a search using agile. It has a key word and you will find resources in there. And these two guys are already almost finished. They are still into the project to form. And by the way, Chris Frost is leading one of those teams. And I think that content is going to provide more specific guidance on the topic. Thank you. Can I make a follow up comment, Steve? During the event this week, you've seen several presentations. In fact, Chris also covered it here today, Chris Frost. If you're wondering how to use TOGO in an agile context, please do this. Set down the myths, but the thing is a waterfall construct. Take a step back. Look at how many of the artifacts in it are related to setting a business context and guidance for scaled teams of various scales and assess its applicability to the problems that you have. There's nothing in the TOGO framework that declares it as a waterfall construct. And there are many instances over the past decade and a half that I've been involved with this organization, both as a user of the TOGO framework and as a developer of it that make me shake my head when I hear this context for pure waterfall environment. Just honestly, I struggle a lot with this idea. I know you do. We've had many conversations on that. So sticking with agile, Vishal, I think I'll come to you on this one. You, obviously for the debate purposes, took the argument that agile teams maybe don't need EA so much. Now that you're unconstrained by arguing that position, what's your real view? Yeah, it's imperative that these two can obviously coexist and the real power comes when these two frameworks complement each other. So as enterprise architect, that's the true value and that's where the value will be maximized and maximum realization can happen. Okay, thank you. Switching to Archimate. So either John Baptiste or Mark maybe jump on this one. Let's see. The big challenge with manual modeling is that most systems never budget in story points for creating and maintaining the models. Definitely not the latter. The direction should be using automated tools to create and maintain the models. So obviously there are tools out there. Can you comment on the comment? You're both coming with the use of tools. I think you should distinguish models of the existing landscape and you can also make that quite well. And we do that as well. You can get data from all kinds of sources, CMBBs, other sources and automate that. But the design of the future, you can't automate it. You have to design it. So that's something you need to do. And of course, tool support will help you do that. But there's no way that the design of the future will automate itself. That's where you need to put in the effort. And of course, if you then use that again, once you're going live with your system as the baseline for further evolving the model partially automated, I think that's the way to go. But it's not just models. It's documentation in general, of course. If you have, let's say, a sound definition of done in an agile world, the documentation of what you build is part of that definition of done. It's not. It compiles on my machine. That's not the definition of done. So it's just part of the work. We should automate more and more the creation of these models, and we do so, especially of the current state. You don't want to do that manually. And keep track of that. It's just too much work. And architects are not the bookkeepers of the present. Right. That's a good sound bite. John Baptiste, I'll come to you for this one. It's a related question, I guess, that the learning curve of modeling standards like Archimate remains a challenge. Organizations find it easy to pick flow charts versus modern modeling frameworks. What's your advice on this context in terms of getting modeling standards like Archimate adopted inside an organization? That's a very good question. In fact, I guess that what is hard with Archimate is starting from scratch with nobody to help you. Because you'll end up trying to use most of the concept that you have in Archimate, and at the end you will not be able to really create something. And the learning curve will be bad. My main advice would be to be helped by some people. And this could be the community. And that's one of the reasons why we decided to create this community. It's to maybe see that there are some usual questions that people have. For example, if you work in a field of, I would say, applications, having a map of your application in your landscape together with flows between those applications can be one simple viewpoint, which rely on many two concepts in Archimate and which is useful. So I would say that what people should try to do is to be helped by some people. And again, this could be the community that's the goal. And try to start small with only key viewpoints, which are needed in the field. And I would say that there's no reason that something which is already produced using other things like Powerpoint, V0, such tools can be the Archimate. OK, thank you. Andrew, this one's perfect for you. The Togeff Library can be difficult to navigate if you're not sure what the publication name is. It may be that the topic can be covered in several publications, but how do I find out? Will there be an intelligent front end for information searches? Well, some good news there is we will be replacing updating the whole of the publications library in probably next month. And we will have elastic search on the front, so that's going to improve things a lot. At the moment, the technology it's built with is actually well known for its poor search capabilities. And we will be replacing that. So your elastic search, I think most people are aware of, is much better at contextually finding things. So we'll be able to search through all the descriptions. Obviously, we still, as editors, and we still got to put together good descriptions that mean meaningful descriptions to help the search. But yes. OK, we're getting a new flood of questions coming in, mostly on Archimate at the moment. Let's see, where to place it. Ah, here's a good one. It relates to an earlier question that came in about, for the new community activity, does it matter what tool I created my models in? So hold that thought and then come to, is Archimate leaving the Archimate file format to the exchange format? To me, the Archimate format works better for reading and would be much preferred. So two parts to a question, I guess, there. I guess the easiest answer is that the goal of the community is to share things for people to be able to access this content. So obviously, we decided to emphasize the use of the Archimate model exchange file format, meaning that people can use it using any tool, which supports its format. And of course, we don't block people attaching other formats. So if you decided to create your model using, I don't know, a business design tool or Archi tool, just upload the model in the exchange file format. And in addition, maybe share the native format. And what we would also like people to do is to share things in an easily readable format like PDF or HTML so that people don't have to download the file, open it in a tool. So exporting the model, publishing it in PDF could be a good solution also. OK, thank you. Could I just follow up? What we need folks to understand about the Archimate user community is that actually it's just launched and is a work in progress. And we expect, and I need to thank JB and Kelly, Gerben, Dr. Figue, everybody who's been involved in trying to jumpstart this thing, recognize that it's work in progress. And actually we're expecting these kinds of questions to shape how the community develops over time. It genuinely is something we expect the folks asking the questions here to jump into in the community and help shape. There is no single answer to the questions. We're just trying to put a framework in place to get us going. OK, thank you for that clarification, Chris. Let's see. There is, let's see, a suggestion for the community. Let's together build a collaborative model in the new open workspace. So is there any thought of building things collaboratively there? See a thumbs up from Chris? Yes, the funny thing is that when we first decided to create this community, we had the kind of brainstorming session about what we could do with it. And we thought that maybe at some point in time people would want to collaborate and create contents. But our first idea was that it was too early for that. And then we boosted up the community with people that we know, so Gerber and Nicolas Figuille and lots of other people that are known in the archimage field. And one of the first questions we had is, is it possible to collaborate? So we decided to make it possible for people to create kind of work groups so that they can have their own space on the platform and so they can work as they want. Of course, it's not a real collaboration platform. They can share content, they can co-create wikipages. But there's no tool behind. So people will still have to rely on their own tooling to be able to model things on their own and share it. But that's something that is supported by the platform. OK, thank you. Great to see. A question here on Togeth, well, sorts of Togeth and ODEF and Togeth. How does an existing open group standard relevant to data architecture get visibility within Togeth? Maybe that's one for you, Sonja. Yes, of course, Steve. That's a very good question. Actually, we also have a couple of guys that are working progress to deliver more guidance and data management. There's one guy that has already been published, which is an information references model for business analytics that's already available in our library. And by the way, it has very nice archimane models. Actually, Yembeptis work engagement that work along with one of our members. So that guide is already published and it's going deeper into the subject. We also have another guy that is coming soon about data management. And we have another working group into the architecture forum, which is data integration that are working in a white paper to cover the subject. So that's it. But we have already published and the work in progress in relation to data. Okay, thank you. Related question, but this is on the Archimate. Will Archimate be addressing the data architecture in the future? Well, it does already to grab data architecture at a certain level. You have some questions, where to, let's say, stop modeling in Archimate and start modeling in a more detailed language like, say, UML, which is more targeted towards that level of, say, data with attributes, et cetera. Archimate doesn't intend to be the one and only language that covers everything in all levels of detail. It's also not going to replace, let's say, BPMM for process modeling. So there is a certain level of data modeling possible in Archimate. And at a certain point, when you need to add more detail, you want to switch to, say, UML or other data modeling approaches. Now, of course, you can discuss how much detail you want to have within Archimate and where that boundary should be. That's a metaphor for the people in the Archimate forum to discuss and what's confated as. One risk might be, if you want to add details on data modeling or details on process modeling, that the language will grow and grow, and the problem becomes larger and larger to learn the language. Like Charles was saying, you have to very precisely select what you need and the bigger the language becomes, the more difficult that becomes. So that will remain something, yeah, we need to strike a balance there and not grow and grow the standards to cover everything. So yeah, that will be an ongoing discussion probably. Right, thank you. Chris, if I can come to you on this one. Chris Frost, sorry. If I can come to you on this one. Agile approaches appear to be, I'm trying to summarize this. Agile approaches appear to be more relevant in some environments than in others. Do you see any, and I ask this because you have some experience of government related contracts and commercial contracts. Do you see any particular environments where Agile is not being embraced as much as in others? Or I guess another way of putting it. What kind of environments have you seen where an Agile approach is taking off and which ones where perhaps a more traditional architecture approach is taking off? And the question just to be clear is about Agile architecture. So it's not throwing architecture away as such. Yeah, interesting question. And as a simple answer, I haven't seen any particular sort of business sector that's more or less following Agile architecture techniques and certainly between public and private sector. Yeah, not really not a lot of difference I could see. I've had experience of some large public sector and large private sector organizations that are quite aggressively adopting Agile delivery techniques and Agile architecture with that. There are some geographic differences, different parts of the world are adopting these things at different paces, but that's not really specific to Agile delivery techniques. That's just following the general trends you see across the globe in the rate at which different countries and different regions adopt new technologies. So you do see some differences across the globe in that sense, but if you look at business sector by business sector, I wouldn't say there is any one that stands out as either leading or lagging to be perfectly honest in terms of types of system. If you read a lot of the literature, it's often said that things like perhaps very safety critical systems, for example, that need that rigor of very tightly defined technical specifications and very tightly defined requirements to go with them might not be quite so suitable to Agile architecture and Agile delivery techniques, but I have to counter that by saying personally, I've not had experience of that effect, but yeah, I know if you look in the literature, that is sometimes what is said. All right, thank you. Back to Arcumate here and the exchange format. So it's a statement with a question at the end. So it turns out that the exchange format leaves some freedom and I've encountered differences, especially in terms of layout of diagrams. The model is okay, but for instance, different tools save different things. So if you share a model, it will look differently. Will there be an initiative to drive tool providers to make diagram layouts to be more exchangeable or make the exchange format more prescriptive here? Any thoughts on that for those in the Arcumate forum? Yes, the thing is that we start to see the benefit of the exchange file format by people actually using it and exchanging models. So of course, now that it is used by some people for several use cases, I've already seen people trying to work collaboratively on the same model by using several tools from different tool vendors. So we are now facing these kind of questions. We had also some time ago, people asking for making idea persistent. So this basically leads us to a kind of balance that we have to find between having a format which is very, very precise, but that no tool supports or having a format which is maybe in some cases a bit loose, but which is supported. I guess that we are at the beginning of the story, even if the format exists or has existed for the past three or four years now, and we have to improve it and that's an ongoing process. For example, we are still not able to exchange stereotypes or customization of concepts and that's something that should be remedied in the future because people will more and more use our akimat for some specific context in which they will use customization. I have lots of, I know lots of people are using it this way. So we have to improve it and we need feedback and we need people using it more and more. Right, okay. A specific comment on this one, a follow up question there. Those involved for both business design and Archie are represented on the panel. Will they work on this? Put you guys on the spot. As you can imagine for software vendor, there are many, many requirements coming from many, many directions. So the only thing I can say is that if you're a customer of business design and you have an interest specifically in the exchange format, make sure that we know about that because, prioritization is always difficult. There's always more work to be done than that we have resources. So it's like that and we have invested quite a lot in the past and that's also something that we think about. Yeah, we put in a lot of efforts. How much can we keep up doing that? Understood, understood. Yeah, I would just have a few things, Steve. Sorry, go ahead, Ed. Yeah, I'll just say in the actual, when we developed the format, as Mark said, that we did bring as many of the tool supplies together as we could and obviously if there are others out there who want to join in the interoperability testing, we welcome them. We try and round rob in the models through the various tools as best we can. And so that's what we'd say is come in and join us. We've got an area on the GitLab project for the exchange file format. More than welcome to have other tool suppliers come in and basically exchange the models we can get them looked at and we find out quite a few things. As we did that, such as how you scale the model, your various coordinate points and so on. It's really through use and of course there's a lot of uses we see of the models that we haven't even imagined, which is the actual success. It's been picked up and used actually outside tools for all sorts of things. It's very successful. I remember when we set off back in 2012, thinking people told us we couldn't do it. Chris, did you want to add something? Yeah, it's maybe just my reading of the comment, but I want to make sure that people who are listening understand that it's not folks like me and Sonja turning around to representatives of various commercial products or open source products, dictating what components of the standards folks will work on. There has to be a common perceived value across the membership in order to work and prioritize a topic. This goes back to Mark's comment that for commercial organizations like Business Design, there are a lot of pressures for folks volunteering their time like JB. There are a lot of pressures. It's where the business value converges inside the open group for members, but that's where they tend to spend their time. I'm not dismissing the question. I'm just trying to give a little bit of insight about how work gets prioritized by the membership about what to deliver into the standard. It's both a combination of the external communications that we get through these user groups and the priorities that the members of the open group see about where updating the standards will add business value. Right. Yeah, and I know you're absolutely right about the different priorities. And I don't know who actually wrote the words, but in the guide that Mark was talking about earlier in his session, I noted down something that I loved, which was that models can help you have a better way of prioritizing than decibel-driven prioritization. I loved decibel-driven prioritization. I love that Mark, it is, yes. You've got a lot of voice, students shouldn't always win. No, that's right. The eldest voice shouldn't wheel, and the squeaky wheel shouldn't always get the oil. I love the term, so good one. And it shows I've read the guide as well, Mark, so that's good. So we are out of time, but I do want to go to this one last question because I think it's interesting. Anyone feel free to chime in? But the question is, for data architecture modeling, we can use semantic ontologies. Is it possible to envisage having an ontologies of archimage models, i.e. integration of EA, archimage and semantic technologies? Yes, it's a head scratcher. Yeah, that's really interesting because we, I remember we had a presentation, it was something like maybe three years ago at Amsterdam where we discussed the use of ontologies and knowledge covered by archimage model that was the topic. And at that time, we imagined that maybe in the future we could have some kind of a chatbot which could answer a question for architects using models. So I guess that it's not very difficult to convert an archimage model or any model to some kind of autonomy. The question is more about how to make it stand out. They are already on the internet some ontology for archimage. So the question is, does this make sense for the open group to end the archimage form to create such kind of, I would say, default ontology for archimage? And as Chris said, that's an interesting question but we have to prioritize things and for the moment that's not on the top list but that's an interesting question. But people can already try to do something on their own, they can look on the internet, there are things about it. So if someone comes with some interesting use cases and does something for sure we'll look at it and see how we can standardize it. Thank you, okay. I'm gonna be respectful of people's time there are some people who are, for them it's very late attending this right now. So we are five minutes over so I'm gonna draw the panel to a close but thank each and every one of our panelists. We shall Sonya, Chris Frost, Jean-Baptiste Suridi, Mark Langhorst, Chris Ford and Andrew Josie. Thank you all for your insights and for answering questions. And thank you all to everyone who submitted a question and to everyone who's attended today. That will bring us to the end of this session. I hope you found it useful. Please do go to the ratings channel on the left hand side of your screen. We'd love to see what you think of this and other sessions that you've attended. And thank you all, that's it for today. Thank you all for joining and keep well and be safe wherever you are.


But if y'all haven't met me yet, my name is Dustin Schaefer. I'm also known as the KeepPro, Ketone's Greater Lukos. And yes, I got water on myself. So don't judge. Stop judging me. Hey, so we're excited. We just finished a challenge and we're gonna kick out another challenge.  But before we do that, if you yourself is looking for energy focus or fat loss, any one of those, or hey, listen, I'm an athlete, well, I used to be, if you're looking for performance, put performance. So energy focus, fat loss, or performance. The truth is, if you're looking for performance, focus is performance, right? Energy is performance. So in the chat down below, I want you to hit me. Energy focus or fat loss? Energy focus or fat loss? Or if you're an athlete, let's talk performance here. So we're gonna do another 10-day challenge. It's actually, we're just gonna call it a challenge. It's actually gonna be a little bit extra. There's gonna be a bonus. There's gonna be an accelerator into this challenge and I wanna invite you to participate. So if you have somebody that's interested, hit them up, tag them and get them on here and let's go do this with up John and Zagay. What's up John, how are you? I'm very excited. And if you did the last challenge in the chat, just give me a little shout out of what you get. I mean, I literally watched a 71 year old woman do 71 burpees. A 50 year old woman do 50 burpees and she outperformed her 28 year old son because of the challenge. I watched an athlete drop nine pounds of fat in the 10 days that we did it. Nine pounds of fat.  Just 20 people interested in doing the challenge because she committed and went for it, right? We have Sarah literally in Iowa who she got some health challenges going on. She's like, I'm gonna do it anyway. I literally watched her go from to, even though she's got the challenges in her life, she did this challenge and it shifted her mood and she started living and feeling better. So the 10-day challenge, I just keep saying 10 days, we're just gonna say that the challenge is starting. I want you to write this in your calendar July 8th, July 8th. If you're ready for a challenge, July 8th, I'm gonna tell you what it is. I'm gonna tell you what it looks like. I'm gonna tell you what to expect. Hey, hey, Ducks Girl, girl, Ducks Girl. It's fun watching and reading our tags. And Facebook, it's like, hi Laura. And Instagram and TikTok, it's all made up, right? It's all something else. So here we go. If you're ready, if you're ready, wow. I've lost 30 pounds in four months. Nice, John. John's down 30 pounds in four months. Aunt Pegg is pushing. She's going for the 2-0-0. She's over 120 pounds down. And that's fat loss, y'all. I never once used this for a fat loss tool, but we're gonna talk about the challenge. July 8th, write it down. July 8th, what is the challenge? The challenge is exactly what it says it is. It's the challenge. What's happened? I just got off a call with the lady and she's been doing Weight Watchers for 28 years. And guess what? She's no closer to her goals than she was 28 years ago.  And I'm not saying Weight Watchers doesn't work for somebody, but it's probably not your solution to your future. It's probably not the solution of what you want. So the challenge, I want you to think about this. The challenge is an environment to basically launch you into a health path that you wanna live in that isn't regimented by numbers, isn't regimented by calories, isn't regimented by, I have to follow the strict plan. It's a process. So the 10-day challenge is the ability to challenge you to push you further towards where you wanna go. Because I'll tell you this, if there's ever a doctor, a health coach in the entire world and they tell you, here's your plan and this is exactly what you should do, you should run the other way. It doesn't exist. Everybody's different. I work with the number one leading doctor in the world of autoimmune health and cognition, brain injury health, because that's me. And he's like, Dustin, he goes, I can give you guidelines, but we gotta figure out you. Like, and he is the best in the world and he can't give me the perfect plan and that's what we do with the challenge. The challenge, we're gonna give you the framework. We're gonna give you nutritional tips. We're gonna tell you what to start to eat with, but we ultimately want you to figure out you through the journey and the process, which takes more than 10 days, by the way. So the challenge is an accelerator. It's the ability for you to accelerate your health and your results so that you can ultimately start to learn who you are and what works for you. What works for you. This is the cheat code of getting results quickly so that you can start working towards your goals. And if you just want a little, a tween up, a tween up. If you just want a little tune up, you just want a little bit of a challenge, then do for that too. But long-term, this is the set to get you going. If I can lose almost 106 pounds, anyone can do it. Absolutely, 160 pounds down, woo-hoo! Duck's girl, yearl, duck's yearl. I don't know how to pronounce that, but anyway. When I present and I have like the teleprompter, I'm always like, they don't write the real name. They write it as if I read it, it sounds real. So that's what happens. Okay, so here we go. So the new challenge is this. You're gonna get ketones.  You're also gonna get nutritional. What do I eat for those 10 days? What do I eat? Let's call it 12 days, 13 days. It's gonna be a little bit more. We have a special gift coming with you guys. So what do I get? What does that look like? Number two, you're gonna get physical activity that you can do if Peg can do 71 burpees because they were modified. I didn't do eight count bodybuilders for United States Marine Corps for her, but I gave those to Janet because Janet's at a different level. So we got the good, better, best. We allow people to find what works for them. You're also gonna get challenged in mindset. What I can tell you for a fact, there's two things that will guarantee you the best result. I will, I'll say three things. Drink ketones daily. Number one. Number two is work on proving your mindset. I know it sounds so crazy, but if you start improving this, your results get better. And then the third and most important one is socialize it. Accountability is the best when you tell people you're gonna do it.  Kind of holding you yourself accountable.  Who's coming with me? And then you tell your story. Guess what? Those days that you don't wanna do it, you kind of have to now because you already made the commitment. You already told them you're gonna do it. So those are the secrets to results. We're gonna take you through that whole process.  I'm not gonna do that.   Because if you wanna be better, if you wanna be different, you gotta do something different than what you're currently doing. Does that make sense? If I wanna make a million dollars a month, I can't do what I'm currently doing because I'm not doing it already. Does that make sense? I gotta do something that I'm not currently doing to get to that result. And yes, I did say that's the numbers, I did say those numbers because that's what we're gonna do. Why not? If you can, you might as well. If you can't, you should do it anyway. All right, so the challenge is, it's 10 days with an accelerator. The accelerator is, is we're gonna add the keto reboot. I'm not gonna talk about the keto reboot. Just all you need to know is it's an accelerator.  You're gonna grab the reboot. We're just gonna accelerate your result. It's gonna lengthen an extra three days and you're gonna get the top coaches in the world. The coaches that are gonna coach you have well over a hundred years collectively of coaching, have coached millions of people worldwide and they're yours for free. You get to use them, be part of them. You get to, we have a cool Facebook group with a hundred thousand plus people. You're gonna get everything you need to be successful in this. So I'm pretty fired up. There's Peg. Peg at 71, doing 71 burpees. Yeah. So July 8th, write it down. The challenge is gonna start. July 8th, the challenge is going to start. Are you ready to shift?   And y'all, life is a journey. It's a process. I'm just telling you. It doesn't end with 10 days. My challenge to everybody out here is take your picture right now. I can show you pictures six years ago when we had our first baby. I, we took a family picture. I like that.  And I can show you now our family pictures. I look younger today than I did six years ago. I am the exact same weight. I don't change weight. My weight is exactly the same. I look younger. I'm as fit. I feel as confident as I did six years. I feel more confident than I did six years ago. So the reason why is because I drink ketones daily. I keep challenging myself for better. I work on my mindset and I do it with a community of people and I tell the world I'm gonna go. I tell the world what I'm gonna do because it's accountability for me. So your journey is a process. So July 8th, 10 day challenge or the keto challenge is starting. The challenge is starting July 8th. And it's simple.  You're gonna get back to them. We're gonna teach you when to drink it, how to drink it, how simple it is, how easy it is. We have an unbelievable guide that's downstairs and I can't show you. I have a guide.  And so we're gonna walk you through this whole journey. So if you're ready for better, all you have to do is in the chat down, just put challenge down below. If you're ready to challenge in the chat, put challenge down below. Just hit me, challenge, challenge, challenge. Tick tock, I'm sorry if you put challenge down below, I'm not gonna be able to respond back. So you may have to come over to Instagram or Facebook and hit the Keto Pro and hit me a message unless you can message me. Sorry, tick tock. Tick tock's working on their platform. Hard to do. Laura's in for the challenge. All right. Jennifer's in on the challenge. This is fun. Tammy's back on the challenge. In the drops below, I want you to hit challenge. Challenge. Shauna's in the challenge. And hey, we're gonna do a game. We're gonna have some prizes. It pegs back on the challenge. We're gonna do some fun stuff with this, y'all. We're gonna have lots of fun with it. So here's another little step. I wanna take it a little bit further. Christie's in the challenge. Yeah! Right out of Florida. I love this. This is good stuff. Who else? Like, come on, let's keep it going. Who's in this challenge? I wanna see it. Here's what I wanna tell you. We have this system. We have this process. We have a product that's completely shifted and changed his lives. It starts with ketones. Ketones are the momentum starter. Why? Because your brain, duck girl's in the challenge. Your brain needs it. It fuels your brain. It fuels your muscles. And it reduces sugar and carb cravings. It's scientifically backed by the top scientists in the entire world. Billy Joe's in the challenge. This is fun. Jessica's on there. She's in the challenge. This is the thing that we've been waiting for.  And it's scientifically evident. And if you do your research, your research should only be from major universities and NASA and the Department of Defense. If you do your research, and it's from somebody's website, you're doing the wrong research. Look at the people, the top minds in the world. Look at the top minds in the world and they will prove it to you. I use the word prove it on purpose. The prove it to you, why this is the breakthrough that it is and why we're seeing results so quickly. But it all starts with just kickstarting the challenge. Get the challenge in. So we're gonna challenge with an accelerator. It's called the reboot. Do the reboot. Just grab the challenge kit and accelerator. Grab the reboot kit, which will accelerate your results. So that's all you have to do to get started. What is the challenge? I missed the first part. The challenge is the challenge. Hit me a private message, obias pizza, obio pizzas. I'll follow up with that. Otherwise we can, you can watch the beginning of this. But obio pizzas, hit me a private message. I'll shorten it down. Otherwise it would take 20 minutes. I don't wanna do that to everybody else. All right y'all, last thing. Here's the last part of this. So we do this and we change lives. Right now we have Aunt Peg on here that's helped 20, 30 people with the challenge. She's down 100, Aunt Peg's almost 60 years old. She's down 120 pounds. And now she's helping other people do the same thing. So if you're interested in helping other people do the same thing, then come do the challenge with us and just say challenge plus, challenge plus. Hit me a challenge plus and let's get more people to do this together. Because there's an opportunity for you to help people while you do this. And why would you not wanna do that? If there's something out here that can help you why not help others? And there's obviously a big way of doing that and there's a lot of rewards for doing that. So it's on, yes Peggy Rumbles, freeze. I love this, this is super excited. So challenge plus, if you wanna do the challenge and help others, hit me that, hit that message in the chat and we're gonna take care of you. We're gonna reach out to you. We're gonna say hi to you all. Jennifer is in the challenge plus, this is awesome. This is fun. I have never done this style before. But if you're looking for more and if you're looking to be part of something really cool right now we have a team in Iowa that's going absolutely bonkers. And a lot of them are moms. A lot of them are hospital workers or just people that care about people and they started feeling better, started living better. Now they have a team growing out there in Iowa and they're expanding. And now people are taking the opportunity that's given to them to not only help other people but be compensated for that. So wherever you're at and whatever you're looking for it's available here but it all starts with July 8th kicking off the challenge. So y'all I gots to go. I can't stay here but I'm super excited. The challenge is on Liz is in the challenge.   It might take me a little bit of time. So we got lots of people in the challenge. We got lots of people doing the challenge plus. That means you're doing the challenge and you're gonna have other people do it with you.  Make sure you get your kit and make sure you are all in the Drink Ketosis Facebook group. Now you're the only way to get in that group is you have to have our product to get in that group. It is the only option to get in that group you must have our product in that group. So I hope that makes sense. If you don't have product get back to whoever invited you to this live and get on with them and say I'm in I'm ready for the challenge. I wanna get my kit and I wanna get my reboot kit. I wanna accelerate these results. I wanna get my kit and I wanna accelerate my result with the reboot kit. That's all you have to tell them. They'll take care of the rest. They'll get you set up. And it's game time. What's up Janet? Janet crushed the challenge also. And everybody in Iowa, I will see you on July 8th. Share that to the world y'all. I'll see you on July 8th. This challenge will be great for you Carol Mack. Carol, let's go. You're in the challenge. Let's go. Hey really quick before I hop off any questions for me at all any questions at all.  I wanna invite to the challenge. Listen, come be a promoter with us. You can share this. Come be a promoter with us. We'll even give you rewards for sharing it. It's not hard, it's not rocket science. It's all you have to do is do the challenge, share the challenge. Do the challenge, share the challenge. Do the challenge, share the challenge. That's it. The coaches do the rest. And guess who gets rewarded? You do. Pretty fun, huh? So we need a flyer. It's coming. It's July 8th. We don't need a flyer until the day before Jennifer. Don't worry about it. Talk to people. Tell them, save the date. July 8th, Iowa. If you're in Iowa or within 25 hours of Iowa driving, come to Iowa. I'm gonna be there. Absolutely blow it out of the water. Northern Iowa, not too far from Oka Boji. I say that because it's like the only landmark in Northern Iowa that I know of, at least. All right, y'all. Any questions I'm looking through, looking through? Hey, TikTok. If you guys wanna learn more on TikTok, come over to Instagram. Unless you can message me. I have a lot of followers. It's hard for me to find out. It's hard to message on TikTok, to be honest. Facebook, love you all. YouTube, it's game on. YouTube's starting to expand and grow. So if you guys want a lot of cool videos, I have everything housed on YouTube. The Keto Pro on YouTube, you can go over there and just start plugging away at it. There's so many resources, things that you can share off to other people. A lot of different hacks. I have a lot of things on plateauing, on Keto. All these different tools there. So go over there and grab it. Also on Instagram, I have a lot of my IGTV saved in little categories. So you can jump on there and get a lot of resources too. So yeah, I gotta go. Hey, hey, hey, sorry. Been watching the Solar Ease. Oh yeah, that's right. Everybody give a shout out and thoughts and prayers to Janet Rodduck's son. Actually, I forgot your son's name Janet, but he is summoning right now. And he's up in Alaska right now doing the big summit. So he should be summoning, I'm guessing tomorrow-ish or the next day. Maybe right now, I don't know if he hit the summit right now, it's kind of early there and it's kind of lighter there. So he maybe could be summoning tonight. But Janet, I think that's just super amazing, super proud of him, proud of you for raising such a strong young man and willing to go for his dreams and willing to work hard towards it. Because a lot to be said about that in you. That's a lot to be said about that in you. And you are leading him by what you're doing right now at 50 years old doing 150 pushups by crushing burpees, by becoming the best version of yourself, so big shout out to you. We love this, Iowa girls. Yeah, Liz, we're gonna make Iowa famous finally. For the first time, Iowa's gonna be famous. Well, let's just say Northern Iowa. Iowa's famous already, right? It's one of the 50 states. Yo, I gotta go, appreciate you all. The challenge is on get your kit today. Do not wait, get your kit. Whoever invited you, it's really important. You get back to them, so they get credit. Credit is important. We're a team, we're a community. We wanna make sure we take care of the team, take care of the community, get people the credit that the credit is due. And they did that by inviting you here and let me jab my mouth off so that you could learn from me, not from them, because guess what? They're not a keto expert. They're not an entrepreneur necessarily, not yet at least. And they don't have a team globally, so I kinda have a little bit of the knowledge and the inside scoop. So I'm gonna be doing the talking, they're just doing the sharing. Good night, y'all. Yes, I'm looking at my screens, figuring out what to do first.