FRDM (pronounced free•dom) delivers enterprise-grade Software as a Service that’s transforming how businesses manage risk (like child labor) and increase transparency in their supply chain

FRDM

frdm

The exchange-traded fund, or ETF, has become such as successful vehicle for investing that there is likely one for any situation you can dream of. From countries with economic freedom ( ) to the metaverse ( ), you might be paralyzed by the . How can you make sure to choose the appropriate ETFs for your portfolio? FRDM META abundance of choices Where Do I Find Good ETFs? When searching for ETFs, it’s best to first narrow it down with a specific type of objective in mind. Are you looking for a specific region (e.g. China, Europe, Emerging Markets, Domestic)? Are you looking for specific company size (e.g. large-cap, mid, small, micro)? Are you looking for certain themes, commodities, or sectors (e.g. technology, semiconductors, energy, gold)? I would suggest searching via Google rather than your brokerage because the latter will bias results in their favor. The is a popular website that displays a wide selection of ETFs. If you are looking for other options, I would suggest googling “ “. ETF Database ETF Screener If you are not finding what you are looking for, here is a list of some that I have encountered over the past few years. ETF providers Ark Blackrock Cambria Funds Charles Schwab Direxion Fidelity/iShares Invesco JP Morgan Roundhill Simplify State Street Vanguard Wisdomtree Where Will This ETF Fit In My Portfolio? Most investors, myself included, preach diversification of assets within a portfolio. If you adhere to this advice, then you need to establish where this ETF will fit in with your existing assets. This first step is establishing your objective for the ETF. Some key questions to ask yourself are whether this ETF will be: Short term/Tactical vs. Long term/Core holding? Held in a taxable vs. non-taxable account? Domestic vs. International Developed vs. Emerging Markets stocks? High vs. Medium vs. Low dividend/shareholder yield (i.e. value vs. growth stocks)? Large cap vs. Mid/Small Cap vs. Diversified cap size? One sector/industry vs. Diversified sectors/industries? What Does This ETF Contain? ETFs typically contain a basket of stocks or bonds; however, some will include other types of assets (e.g. commodities, crypto exposure, etc.). Using the as an example, we can locate their documentation to further understand what is in this ETF. Within this documentation, the assets being held are often described in the “Objective”, “Overview”, “Portfilo and Management” and “Holdings” sections. Within the documentation, you can find out the following characteristics of VTI: Vanguard Total Stock Market (VTI) “Seeks to track the performance of the .” CRSP US Total Market Index “Large-, mid-, and small-cap equity diversified across growth and value styles.” Top 10 holdings include Apple, Microsoft, Alphabet, Amazon, etc. 27.6 percent is in the technology sector 1.37 percent shareholder yield This information informs you that this is a diversified portfolio of U.S.-based stocks across all industries and sizes. If you want more details you could dive deeper into the that this ETF tracks. ETFs that track an index are “passively managed” (i.e. less active) than ones that are actively managed (e.g. ARKK fund). The active managed ones tend to change holdings more frequently and are often more expensive than the passively managed funds. market index With a shareholder yield of 1.37 percent (i.e. blend of value and growth), shareholders can expect a return of this amount of money for each share. refers to buybacks, debt paydowns, and dividends, while dividend yield only refers to dividends. Value companies tend to have higher shareholder yields and return more cash back to the shareholder, while growth companies tend to reinvest their earnings back into the company. Shareholder yield The objective of the fund is not something to be taken lightly. Because of the popularity of ETFs, there are many available that are more complex than your traditional index fund. If a fund factsheet mentions words such as “leverage”, “covered calls”, “managed futures”, “hedge”, “options wrapper”, or other advanced financial terminology, then you should probably avoid it unless you have a solid grasp or seek a financial professional’s opinion. How Active Do You Want To Be? Choosing ETFs that are more tactical require a pre-determined exit plan as opposed to the long term plays which you can HODL. There is a range of how active you need to be with each ETF. While leveraged ETFs are typically held less than year, target date funds could be held for your entire life. In general, ETFs designed to be core holdings in a portfolio (e.g. SPY, VEA, AGG) can be left alone for decades if the investor chooses to do so. How Liquid Is The ETF? Liquidity can be defined as the ease in which you can buy or sell the ETF (i.e. swap it with cash or for cash). While most funds are easy to buy via clicking a button, the level of liquidity will determine how much it costs to move in and out of these funds. Increased liquidity means it will be quicker and easier to buy the fund at a fair price. Lower liquidity will increase volatility in prices for those funds. There are three methods I use to understand the liquidity of an ETF: Spreads, Assets Under Management (AUM), and Volume. The bid-ask spread for a fund is the difference in the price that someone is willing to pay (the bid) versus the price where someone is willing to sell (the offer or ask). Whether the brokerage displays the bid-ask spread for a fund or not, these still exist under the hood. Brokerages like Robinhood opt for simplicity so they hide this detail, while traditional finance firms like Fidelity will display the information to the investor. A smaller spread (or difference) between the bid and ask means higher liquidity. Take a look at a few ETFs below to see how much this spread can vary from the most liquid (SPY) to the least liquid (TRTY) of the bunch. Another indirect method of determining liquidity is to identify how many assets are under management for that fund or the volume (i.e. activity) for the fund. The more popular funds tend to have higher AUM’s and volume, which correlates with higher liquidity. You can often find the AUM and volume for a fund in ETF screeners (see below). Source: ETFDB : A more advanced statistic related to fund performance and standard deviation is . Higher standard deviation means higher volatility, which is a tough thing to stomach in real time. Note sharpe ratio How Expensive Is This ETF? The expense ratio of a fund is the managerial cost for holding this fund. If the fund appreciates 5%, you will realize a gain of <5% because of this fee*. This fee is incredibly important because many of the funds you encounter are virtually identical. It would be akin to choosing between a white sedan and an off-white sedan where the latter is priced 5,000 dollars higher for no reason. Investing newbies, like myself in 2017, will often make their ETF selections solely based off of ETF expense ratios, and the managerial cost of holding the fund. While this is an incredibly important box to check off, it is not the sole consideration. When comparing funds that seem similar, it might be beneficial to see how correlated the funds are. If two funds have 95 percent correlation, or higher, over several years then you likely can choose the cheaper fund. The process for checking correlations is fairly simple. First, go to a website that calculates the correlation between two funds like . Then, enter two funds that you want to compare, such as the Schwab U.S. Small-Cap ETF (SCHA) and Vanguard Small-Cap Value ETF (VBR). I edited the dates to show a longer time period, going back to 2010. Over the past 12 years, these funds had a correlation of 0.98. Additionally, they had very similar monthly and annual standard deviations. Because they are strongly correlated had similar standard deviations, then it likely will not matter which one you pick. Below, you will see a chart of their performance over time and their correlation results. this one and Source: Koyfin Source: Portfolio Visualizer *There are some exceptions, such as the offered by Fidelity. zero-fee funds Applying The Process As you go through this fund selection process, there are many fantastic, free resources out there. Some of my favorite resources that I use frequently include the following: ETF Database/Screener Wisdom Tree Fund Comparison Tool Koyfin’s data research and analytics tools Thankfully, the cost of buying or selling funds is free or nearly free on most platforms. Therefore, it is easy enough to update your portfolio as you learn more over time. This framework should enable you to have a better understanding of the differences between various funds. Some logical next steps would be improving your understanding of sharpe ratios, risk, and modern portfolio theory in order to build your ideal portfolio. ~ The Data Generalist Financial Disclosure: Anything on this website is not financial advice.

How To Identify A Good ETF

Vice-chancellor and Germany's finance minister, Olaf Scholz, says ‘No’ to Facebook, ‘Yes!” to digital currency. "Such a payment system would be good for financial center Europe and its integration into the world financial system,"  Scholz stated  in a local business news magazine, WiWo. published "We should not leave the field to China, Russia, the US or any private providers," Scholz said directing his comment at . Facebook’s Libra Coin Germany recently a blockchain strategy preventing parallel currencies to be issued, just three weeks ago. Scholz stated, “A core element of state sovereignty is the issuing of a currency, we will not leave this task to private companies.” passed “We cannot accept a parallel currency,” Scholz said during a panel discussion in Berlin. “You have to reject that clearly.” The German cabinet is expected to adopt a comprehensive blockchain strategy on Wednesday which aims to boost the digital transformation of its economy but also tackle the risks stemming from such new technologies.In its blockchain strategy, Berlin says it will liaise closely with its European and international allies to prevent stablecoins from becoming alternative currencies, according to a government document seen by Reuters. “The Federal Government will work at European and international level to ensure that stablecoins will not become an alternative to official currencies,” the document said.” Source Some argue Libra would be “Frankly a dangerous precedent” to shut down. Andreessen Horowitz partner Katie Haun, former Ex-federal prosecutor has contended the United States blocking Facebook’s Libra Coin will certainly come with national security implications. If you’re not familiar with Katie Haun, you should be. On October 6th, broke her down pretty well. CNBC In my words, she’s the successful, intelligent, bombshell that went from DoJ to Btc and she’s taking the crypto world by storm. Katie is the first female general partner at Andreessen Horowitz, and co-heads its $350 million cryptocurrency fund. She and the firm have been a driving force alongside Facebook to launch its libra cryptocurrency. Katie was a  U.S. Department of Justice prosecutor, investigating prison gangs, corrupt officials and the mafia. Her assignment was to “take down bitcoin.” Katie reflects; “They said ‘we have this perfect assignment for you’ — there’s this thing called bitcoin and we need to investigate it,” she says. “That was the first time I’d ever heard of bitcoin.” Katie is now one of the most recognizable investors in the industry,  Ben Horowitz calls her, “the credible face of crypto.” reports, “the social media titan’s project was facing “the same criticisms” and misperceptions that the asset class faces more broadly. CoinTelegraph “They were just heightened and they got more attention because of the high-profile nature of the project and the fact that Facebook was involved. I think it would be a really dangerous thing, and frankly a dangerous precedent to start shutting down technology before it’s built.” “Haun underscored her perspective that there are national security implications if the United States falls behind in terms of cryptocurrency development, pointing to plans to launch competitors to Libra by states such as China and .” . Russia Source . Facebook and their Stablecoin relationship woes continue. PalPal officially pulled out Oct. 4th and Mastercard is rumoring to follow suit. Conclusion Do you think CaLibra will end up being a wallet for other digital assets? I don’t have the answers, but it’s exciting to watch, as Facebook ranked No. 76 in the 2018 Fortune 500 list of the largest United States corporations by revenue. What they do with their platform can potentially change the course of banking history. Need To Know More About Stablecoins? I’ve written a lot about them… read more on or . Medium Hacker Noon I’d love to professionally discuss, collaborate and connect with you all. Would love any feedback, positive and negative; as I’m only here to improve and educate myself/others. So, how can we mutually benefit one another? 💻 Let’s Connect on Social Media 📱 @ LinkedIn @ instagram @ Twitter @ Facebook

Olaf Scholz vs. Facebook's Libra 

You’re a North Korean engineer who’s been selected to develop a new government project. It’s an HTML form, which North Korean political leaders will fill in for purposes. [REDACTED] One of the fields requires the user to select the title by which they prefer to be addressed. , you decide to go for your good old > element. It looks like this on Windows (Chrome): Since the list can get pretty long <select Nothing out of the ordinary, perfectly acceptable in most cases. You know that . But you're not sure if the is aware of this. You feel like this is not too big of a deal, as long as the list is in alphabetical order. <select> has that kind of "search" that jumps to the items as you type Great Leader What about mobile? This is how it looks on Android (Chrome): Android tries to use as much of the screen as possible, covering the address bar. Here it is on iOS (Safari): On iOS, the small number of visible items makes for an awful experience with larger lists. Both of them lack a way to search or filter list items. Will the look the other way? Not wanting to take any chances, you take this matter into your own hands. You want something that can be filtered on mobile, and makes better use of screen real estate. Father of the Nation On desktop platforms this is not too hard to achieve: just a custom dropdown with a text input for filtering. For mobile, you’ll need something different. Let’s focus on the mobile version, and presume that you’ll have some way to pick the correct implementation depending on the platform. This is your plan for mobile: A full-screen modal with a fixed text input at the top for filtering, and a scrollable list of items below it. Your first instinct tells you the implementation should go like this: Select a title X Item 1 Item 2 < = > button onclick "openModal()" </ > button < = = > div class "modal" id "modal" < = > div class "modal-header" < = = > input type "text" id "filter-input" < = > button onclick "closeModal()" </ > button </ > div < = > div class "modal-body" < > button </ > button < > button </ > button  </ > div </ > div { : none; : fixed; : ; : ; : ; : column;
} { : flex;
} { : ; : auto;
} .modal display position top 0 left 0 height 100vh flex-direction .modal .show display .modal-body flex 1 overflow-y modal = .getElementById( ) filterInput = .getElementById( ) {
  modal.classList.add( )
  filterInput.focus()
} {
  modal.classList.remove( )
} const document 'modal' const document 'filter-input' ( ) function openModal 'show' ( ) function closeModal 'show' The important bits: to fix the modal to the screen; position: fixed to make the height 100% of viewport's; height: 100vh Modal divided in two parts: header and body; Header’s height defined by its children, no need to set it explicitly; Body fills the remaining height with ; flex: 1 : auto in the body to make it scrollable when the list doesn't fit. scroll-y Works as expected on iOS: But on Android the last items are being cut off: Why? Some mobile browsers hide the address bar when the user scrolls down. This changes the visible viewport height, but not the meaning of . So actually a bit taller than what is initially visible. 100vh 100vh Your modal has , so you don't need to use units. will fill the available height correctly: position: fixed vh height: 100% Neat! This is already an improvement from the native versions of on mobile. Now you need to implement the filter behavior. <select> You’re pretty sure that your wouldn’t want to go through the trouble of having to touch the filter input every time after opening the modal. So you should the filter input as soon as the modal opens. This way, the keyboard pops up and the user can start typing right away. Guiding Sun Ray focus() Everything looks good on Android: On iOS, the modal header is scrolled out of bounds once you try to scroll the list: What’s going on? When you filter by “Leader”, the list becomes small enough to fit the screen without scrolling, but only if the keyboard isn’t visible. On Android, opening the keyboard shrinks the viewport down to the visible area. But . iOS lets you scroll the page while the keyboard is open, revealing that missing portion of the page. This behavior can break elements like yours. on iOS, the viewport size remains unchanged; it is just being covered by the keyboard position: fixed To make matters worse, there’s no way to know how tall the keyboard will be, or if it is there at all (the user can be using a hardware keyboard). No clever CSS trick can save you this time. So you need to have a scrollable list, where all the items are accessible, without knowing if an arbitrary portion of the lower part of screen is visible or not. This is your workaround: You add a spacer at the bottom of the list (highlighted in green for visibility). The height of this spacer is the height of the list area, minus one element. This way, it’s always possible to scroll all the way to the bottom, bringing the last element to the very top of the list. There are still ways to make the modal scroll outside the viewport, and you need to patch them. One way is by swiping on any non-scrollable elements currently visible. In your case, that’s the modal header. You can’t just disable all pointer events through CSS, since you need the inner elements (filter input and close button) to still be usable. The solution is to disable scrolling on events: touchmove header = .getElementById( )

header.addEventListener( , event => {
  event.preventDefault()
}) const document 'modal-header' 'touchmove' The default reaction to is scrolling, so blocking that with preventDefault() will make it unscrollable. touchmove Now let’s take a small detour. I’ve been writing these examples in HTML + JavaScript to make the article a bit more universal. But I came across this spiral of workarounds while developing in React. This is how I define my event handler in React: {
  event.preventDefault()
} <Element onTouchMove={handleTouchMove} /> ( ) function handleTouchMove event // … The expectation might be that in plain JavaScript, this would translate to something like this: element = .getElementById( )

element.addEventListener( , event => { }) const document 'element' 'touchmove' // call the callback for this element But what happens is closer to this (not real code): .addEventListener( , event => { element = React.getElementFromEvent(event) }) document 'touchmove' const // call the callback for this element React binds the events at the document level, instead of binding them at the level of each individual node. Here is what happens when I try to touch events in React: preventDefault() The browser blocks it. , and those can’t be blocked with at the document level. The solution is to bind the event manually at the node level, instead of doing it through React's event system: This was introduced with a Chrome update that made events be “passive” by default preventDefault ref = React.createRef();

componentDidMount() {
  ref.addEventListener( , handleTouchMove)
} {
  event.preventDefault()
} <Element ref={ref} onTouchMove={handleTouchMove} /> 'touchmove' ( ) function handleTouchMove event // … So yes, particularly in React, this workaround requires a workaround. As I write this, , so the problem may no longer exist by the time you read this article. React’s event system is being rewritten Now back to problem. your There is one more way to scroll your hopes and dreams away. If the user insists on scrolling when there are no more items to show, the viewport can be scrolled up. None of this fazes you anymore, you just jam another workaround in there: modalBody = .getElementById( )

menuScroll = { (modalBody.scrollHeight - modalBody.scrollTop === modalBody.clientHeight) {
    modalBody.scrollTop -= }
}

modalBody.addEventListener( , menuScroll) const document 'modal-body' => () if 1 'scroll' You push the list’s scroll position one pixel away from the edge when the scroll reaches the bottom. This way, the outer scroll is never triggered. The solution is already pretty solid, but there is one more thing you’d like to improve. The modal suddenly covering the screen might be a bit jarring. What if isn’t paying attention and gets spooked? Who will take care of your kids? His Excellency A simple transition animation could make it easier to follow. Perhaps you could slide the modal from the bottom of the screen? Easy to achieve with CSS transitions: { : flex; : ; : top ;
} { : ;
} .modal /* ... */ display top 100vh transition 500ms .modal .show top 0 Now, instead of initializing your modal with and , you start it already with , but pushed outside the viewport with top: . When the modal is set to visible, it will scroll smoothly to the top of the screen. Let's see the result on Android: display: none top: 0 display: flex 100vh Android behaving well again! And now on iOS: iOS blasts the modal to outer space as soon as it is visible. It seems like toggling the keyboard while the modal is being animated isn’t a good idea. You feel pretty confident that showing the keyboard only after the animation is done should fix it: {
  modal.classList.add( ) setTimeout( {
    filterInput.focus()
  }, )
} ( ) function openModal 'show' // new => () 500 Simple enough. You wait for 500ms, the same as the transition duration, and only then you the input to make the keyboard pop up. You tell yourself that you'll clean this up later, maybe using events or some fancy library, instead of relying on the values being consistent between JS and CSS. But you know it won't happen. The result: focus() Now iOS doesn’t seem to be focusing the input at all. Of course, it couldn’t be that easy. , and isn't that. Your workaround is to turn the "Select a title" button into a text input: iOS only allows focus events to happen as a direct result of a user interaction setTimeout < = = = > input onfocus "openModal()" readonly true placeholder "Select a title" The hides the caret and makes sure the user can't type anything into this new input during the transition. This way, iOS will show the keyboard based on the first focus event, allowing you to change the focus to the second input after the transition is done. readonly And it works! You’re finally done. You feel proud of your work, knowing your family will live at least another couple months. Find the full code for the modal here

In North Korea, Front End Devs Face Platform Inconsistencies That You Might Not Know Even Existed

Introduction: Ever since the buzz about GenAI and ChatGPT, I have been trying to understand the space and leveraging it into my day-to-day activities as a Data Engineer. No doubt it has been useful for debugging with respective programming and documentation. Personally, it played a significant role in helping me plan my Dubai itinerary. It even contributed to naming my friend’s daughter. However, it works pretty well if you give appropriate and precise requirements. There is a lot of anxiety among people that AI is going to take our jobs as they feel almost everything will be automated through AI. Is LLM as good as everyone claims? In this article, we will look into the specifics of Gen AI’s role in data engineering and see where it flourishes, where it requires enhancement, and where human expertise remains irreplaceable. Areas of Strength: Basic Data Querying: 100% the human necessity is going to get disrupted, but the severity based on the complexity is high. Even the SQL practitioners won’t feel much difference here, and self-serve analytics will catch fire in this area which is something phenomenal! Again, to quote positively, data engineers won’t need to guide the stakeholders nearly as much! Troubleshooting Pipeline Failures: LLMs coupled with agents will slash on-call load massively. LLMs processing stack traces/quality failures can recommend the built-in remedies and nudge the ball down the field to address the problem, presumably even over Slack. And that is a fantastic percentage of data engineering hours saved! To be clear, some hard failures require manual troubleshooting. Anomaly Detection: Regardless of the structure, format, source, complexity, timeliness, or even natural play of data, large language models can identify anomalies. LLMs are well-suited to anomaly identification because they can work across a variety of data sources, identify subtle patterns, and distinguish when data isn’t behaving as expected. This will help data engineers to identify and fix data quality problems in advance. Areas for Enhancement: Data Cleansing: Our results suggest that Language Models (LLMs) are highly effective in data cleansing due to their high performance in unstructured data management and semantic error identification and correction, as well as high scalability. Furthermore, our review of the current state-of-the-art suggests that even more substantial improvements are possible, including fine-tuning of LLMs to specific domains or even organization data. In addition, various interactive mechanisms as well as coupling with data quality frameworks can significantly increase the efficiency of LLMs. Overall, LLMs allow for organizing and improving the whole process of data cleansing, helping to obtain high-quality datasets, and, consequently, valuable insights. Visualization and Report Generation: Language Models (LLMs) excel in visualization and documentation tasks by automating the creation of reports, summarizing data insights, and generating narrative-driven reports. Enhancements needed include improving document organization and categorization, data-driven storytelling capabilities integrating with version control systems and visualization tools for seamless output generation, and enhancing interpretability features to ensure clarity and coherence in reports. Writing Pipeline Code in SQL, Spark, or Flink LLM can be a helpful starting point, and for our work, it is a good boilerplate. Still, the generated material is hard to debug — or often not, worth the trouble. Prompt-driven content is still far from being able to turn out a nice, optimized, and absolutely accurate data pipeline. Optimization By providing suggestions on efficient query structures and detecting problems that slow performance, LLMs are especially powerful when it comes to SQL optimization. They can even make recommendations for optimizations on the basis of historical query data. Things for improvement include integrating database-specific optimization techniques into the training of LLM, bridging with query execution plans in order to give context-oriented advice and feedback mechanisms so that one can modify strategies for optimization according to what users prefer as well as performance metrics. Physical Data Model As soon as the logical model is finalized, LLM will be efficient in moving and upgrading this logical (or conceptual) data model into the targeted architecture. The problem that LLM encounters with all the examples is that it’s hard for most people to understand the pipeline, table, and its relationship. Areas Where Human Expertise Remains Irreplaceable: Logical Data Model Data modeling is a very soft skills-focused task. You have to communicate with different stakeholders to understand the business context in detail. Understanding what data is needed, the relationship between entities, and considering different scenarios are human-oriented tasks that LLMs must continue to struggle with. Building Pipeline and Framework Once they reach a certain level of complexity, LLMs begin to give up. Imagine if someone asked ChatGPT, “Can you provide me the source code of Android’s next version?” While LLMs can help with routine data engineering tasks, they do not have the insight or inventiveness unique to humans that allows for new solutions to complex challenges, unlocking creativity in technical terms. Domain Expertise and Intuition: Human data engineers bring a unique blend of domain expertise and intuition to their work that often surpasses what conventional software isn’t able to achieve through automation. This intuition allows them to find subtle patterns in data that no fully rigorous automated system can. Based on their knowledge of this field and their experiences in it, they can predict future trends. They can also make decisions in light of a broader context, including corporate or government needs, ethical considerations, and potential future scenarios. This holistic approach to data engineering surpasses what LLMs have achieved. Although LLMs have great power, they are typically restricted to the patterns and relationships they have been trained to recognize. Conclusion: On the whole, Gen AI can certainly automate trivial procedures such as looking for information, launching programs that don’t work properly, repeatedly correcting faults, and anomaly detection. My gut tells me that Gen AI will win out and excel at tasks such as Data Cleansing, Optimization, and Writing Pipelines — once the team understands gaps and missing patterns. But it can not learn purely human soft skills that are important for building logical data models or a framework. I believe that these skills, which cannot be automated, are also essential for stakeholders to ask for innovation in the first place. After all, no one ever asked Steve Jobs if they needed anything like an iPhone; he just thought up what would become its invention. References: https://barrmoses.medium.com/will-genai-replace-data-engineers-no-and-heres-why-708b0a27da6b ​​__https://www.linkedin.com/pulse/navigating-data-governance-challenges-era-large-fnq5e__ https://www.dataversity.net/navigating-the-risks-of-llm-ai-tools-for-data-governance/ https://www.skyflow.com/post/why-ai-governance-requires-data-governance https://coreykeyser.medium.com/you-cant-govern-ai-without-governing-data-27bb88d8f9ea https://www.ankursnewsletter.com/p/gpt-4-gpt-3-and-gpt-35-turbo-a-review https://towardsdatascience.com/from-chaos-to-clarity-streamlining-data-cleansing-using-large-language-models-a539fa0b2d90 https://medium.com/@wangshally11/data-cleaning-warm-up-before-training-large-language-models-74ed1edceead Introduction: Ever since the buzz about GenAI and ChatGPT, I have been trying to understand the space and leveraging it into my day-to-day activities as a Data Engineer. No doubt it has been useful for debugging with respective programming and documentation. Personally, it played a significant role in helping me plan my Dubai itinerary. It even contributed to naming my friend’s daughter. However, it works pretty well if you give appropriate and precise requirements. There is a lot of anxiety among people that AI is going to take our jobs as they feel almost everything will be automated through AI. Is LLM as good as everyone claims? In this article, we will look into the specifics of Gen AI’s role in data engineering and see where it flourishes, where it requires enhancement, and where human expertise remains irreplaceable. Areas of Strength: Basic Data Querying: 100% the human necessity is going to get disrupted, but the severity based on the complexity is high. Even the SQL practitioners won’t feel much difference here, and self-serve analytics will catch fire in this area which is something phenomenal! Again, to quote positively, data engineers won’t need to guide the stakeholders nearly as much! Troubleshooting Pipeline Failures: LLMs coupled with agents will slash on-call load massively. LLMs processing stack traces/quality failures can recommend the built-in remedies and nudge the ball down the field to address the problem, presumably even over Slack. And that is a fantastic percentage of data engineering hours saved! To be clear, some hard failures require manual troubleshooting. Anomaly Detection: Regardless of the structure, format, source, complexity, timeliness, or even natural play of data, large language models can identify anomalies. LLMs are well-suited to anomaly identification because they can work across a variety of data sources, identify subtle patterns, and distinguish when data isn’t behaving as expected. This will help data engineers to identify and fix data quality problems in advance. Areas for Enhancement: Data Cleansing: Our results suggest that Language Models (LLMs) are highly effective in data cleansing due to their high performance in unstructured data management and semantic error identification and correction, as well as high scalability. Furthermore, our review of the current state-of-the-art suggests that even more substantial improvements are possible, including fine-tuning of LLMs to specific domains or even organization data. In addition, various interactive mechanisms as well as coupling with data quality frameworks can significantly increase the efficiency of LLMs. Overall, LLMs allow for organizing and improving the whole process of data cleansing, helping to obtain high-quality datasets, and, consequently, valuable insights. Visualization and Report Generation: Language Models (LLMs) excel in visualization and documentation tasks by automating the creation of reports, summarizing data insights, and generating narrative-driven reports. Enhancements needed include improving document organization and categorization, data-driven storytelling capabilities integrating with version control systems and visualization tools for seamless output generation, and enhancing interpretability features to ensure clarity and coherence in reports. Writing Pipeline Code in SQL, Spark, or Flink LLM can be a helpful starting point, and for our work, it is a good boilerplate. Still, the generated material is hard to debug — or often not, worth the trouble. Prompt-driven content is still far from being able to turn out a nice, optimized, and absolutely accurate data pipeline. Optimization By providing suggestions on efficient query structures and detecting problems that slow performance, LLMs are especially powerful when it comes to SQL optimization. They can even make recommendations for optimizations on the basis of historical query data. Things for improvement include integrating database-specific optimization techniques into the training of LLM, bridging with query execution plans in order to give context-oriented advice and feedback mechanisms so that one can modify strategies for optimization according to what users prefer as well as performance metrics. Physical Data Model As soon as the logical model is finalized, LLM will be efficient in moving and upgrading this logical (or conceptual) data model into the targeted architecture. The problem that LLM encounters with all the examples is that it’s hard for most people to understand the pipeline, table, and its relationship. Areas Where Human Expertise Remains Irreplaceable: Logical Data Model Data modeling is a very soft skills-focused task. You have to communicate with different stakeholders to understand the business context in detail. Understanding what data is needed, the relationship between entities, and considering different scenarios are human-oriented tasks that LLMs must continue to struggle with. Building Pipeline and Framework Once they reach a certain level of complexity, LLMs begin to give up. Imagine if someone asked ChatGPT, “Can you provide me the source code of Android’s next version?” While LLMs can help with routine data engineering tasks, they do not have the insight or inventiveness unique to humans that allows for new solutions to complex challenges, unlocking creativity in technical terms. Domain Expertise and Intuition: Human data engineers bring a unique blend of domain expertise and intuition to their work that often surpasses what conventional software isn’t able to achieve through automation. This intuition allows them to find subtle patterns in data that no fully rigorous automated system can. Based on their knowledge of this field and their experiences in it, they can predict future trends. They can also make decisions in light of a broader context, including corporate or government needs, ethical considerations, and potential future scenarios. This holistic approach to data engineering surpasses what LLMs have achieved. Although LLMs have great power, they are typically restricted to the patterns and relationships they have been trained to recognize. Conclusion: On the whole, Gen AI can certainly automate trivial procedures such as looking for information, launching programs that don’t work properly, repeatedly correcting faults, and anomaly detection. My gut tells me that Gen AI will win out and excel at tasks such as Data Cleansing, Optimization, and Writing Pipelines — once the team understands gaps and missing patterns. But it can not learn purely human soft skills that are important for building logical data models or a framework. I believe that these skills, which cannot be automated, are also essential for stakeholders to ask for innovation in the first place. After all, no one ever asked Steve Jobs if they needed anything like an iPhone; he just thought up what would become its invention. References: https://barrmoses.medium.com/will-genai-replace-data-engineers-no-and-heres-why-708b0a27da6b https://barrmoses.medium.com/will-genai-replace-data-engineers-no-and-heres-why-708b0a27da6b https://barrmoses.medium.com/will-genai-replace-data-engineers-no-and-heres-why-708b0a27da6b ​​__ https://www.linkedin.com/pulse/navigating-data-governance-challenges-era-large-fnq5e __ https://www.linkedin.com/pulse/navigating-data-governance-challenges-era-large-fnq5e https://www.dataversity.net/navigating-the-risks-of-llm-ai-tools-for-data-governance/ https://www.dataversity.net/navigating-the-risks-of-llm-ai-tools-for-data-governance/ https://www.dataversity.net/navigating-the-risks-of-llm-ai-tools-for-data-governance/ https://www.skyflow.com/post/why-ai-governance-requires-data-governance https://www.skyflow.com/post/why-ai-governance-requires-data-governance https://www.skyflow.com/post/why-ai-governance-requires-data-governance https://coreykeyser.medium.com/you-cant-govern-ai-without-governing-data-27bb88d8f9ea https://coreykeyser.medium.com/you-cant-govern-ai-without-governing-data-27bb88d8f9ea https://coreykeyser.medium.com/you-cant-govern-ai-without-governing-data-27bb88d8f9ea https://www.ankursnewsletter.com/p/gpt-4-gpt-3-and-gpt-35-turbo-a-review https://www.ankursnewsletter.com/p/gpt-4-gpt-3-and-gpt-35-turbo-a-review https://www.ankursnewsletter.com/p/gpt-4-gpt-3-and-gpt-35-turbo-a-review https://towardsdatascience.com/from-chaos-to-clarity-streamlining-data-cleansing-using-large-language-models-a539fa0b2d90 https://towardsdatascience.com/from-chaos-to-clarity-streamlining-data-cleansing-using-large-language-models-a539fa0b2d90 https://towardsdatascience.com/from-chaos-to-clarity-streamlining-data-cleansing-using-large-language-models-a539fa0b2d90 https://medium.com/@wangshally11/data-cleaning-warm-up-before-training-large-language-models-74ed1edceead https://medium.com/@wangshally11/data-cleaning-warm-up-before-training-large-language-models-74ed1edceead https://medium.com/@wangshally11/data-cleaning-warm-up-before-training-large-language-models-74ed1edceead

LLMs: An Assessment From a Data Engineer

Hey Hackers! As someone who has been writing for years, it can sometimes appear that making it on the first few pages of Google is just a random game of chance. But there are things you can do to increase those chances. Today, we’ll talk about the importance of the meta description and how it can take you to the top of Google. What Is the Meta Description? The meta description is exactly what it sounds like: it describes what your article is about and what readers can expect from it. You can find the meta description box in the story settings. Why Is the Meta Description Important? The reason it’s so important is that Google will analyze your meta description and determine how relevant it is to the keywords. For example, if you write an article about the newest iOS update, and your meta description has zero mention of iOS, iPhone, Apple, or any relevant keywords, Google won’t prioritize it and won’t push it. That’s why it’s essential to capitalize on meta descriptions and make the most out of them. And if you need help writing them, we got you covered. Also need help with story tags? Check out our previous article to learn how to up your tag game. How to Write Meta Descriptions Writing meta descriptions can appear simple, but it takes a little finesse. If you go to the meta description box and just start spamming keywords, that won’t get you anywhere. This is an example of a bad meta description: “ios new update apple new update iphone update new iPhone update apple updates apple news” Now, there’s a slim chance that this can work out in your favor, but it’s not likely. You’ll increase your chances of a better ranking on Google by thinking out your description, and not just trying to take the easy route. This is an example of a good meta description: The new iOS 20.5 update introduced new features such as updated security protocols and new emojis. Here's every single feature of the new iOS update explained. Notice how we have “iOS 20.5 update” and “new iOS update” in the meta description. These are keywords that we’re targeting, and putting them in the meta description will hopefully give us a leg up against other articles talking about the same thing. And that’s it! We now have a good meta description that we can be proud of. To recap, here are the important points you need to remember: The meta description can’t just be buzzword after buzzword; they have to be clear and concise sentences.
Try to add 2 keywords to your meta description (It’s also important to add these words into your title and throughout your article).
The meta description can only be 160 characters, so don’t add unnecessary words. With these tips, and with your talent, we know your articles will shoot up in the Google stratosphere. Put your newly acquired skills to use! Use this template to let us know what everyone should know. It could be about the latest Apple update, useful coding tips, or things going on in the world around us. But wait. There’s More! Did you know HackerNoon is always running writing contests where the winning writers can earn money?? Here are the 5 we currently have going on: The #blockchain-api Writing Contest by dRPC ($1,000 in total prizes)
The #bitcoin Writing Contest by Rootstock ($17,500 in total prizes)
The Opt-Out Writing Contest by Āut Labs (9,000 USDT in total prizes)
The #crypto-api Writing Contest by CoinGecko ($1,000 in total prizes)
The #decentralize-ai Writing Contest by ICP ($1,000 in total prizes)
The #ethereum Writing Contest by DeGate ($1,000 in total prizes) See you next time! Hey Hackers! As someone who has been writing for years, it can sometimes appear that making it on the first few pages of Google is just a random game of chance. But there are things you can do to increase those chances. Today, we’ll talk about the importance of the meta description and how it can take you to the top of Google. meta description What Is the Meta Description? The meta description is exactly what it sounds like: it describes what your article is about and what readers can expect from it. You can find the meta description box in the story settings. Why Is the Meta Description Important? The reason it’s so important is that Google will analyze your meta description and determine how relevant it is to the keywords. For example, if you write an article about the newest iOS update, and your meta description has zero mention of iOS, iPhone, Apple, or any relevant keywords, Google won’t prioritize it and won’t push it. That’s why it’s essential to capitalize on meta descriptions and make the most out of them. And if you need help writing them, we got you covered. Also need help with story tags? Check out our previous article to learn how to up your tag game. Also need help with story tags? Check out our previous article to learn how to up your tag game. article How to Write Meta Descriptions Writing meta descriptions can appear simple, but it takes a little finesse. If you go to the meta description box and just start spamming keywords, that won’t get you anywhere. This is an example of a bad meta description: “ios new update apple new update iphone update new iPhone update apple updates apple news” “ios new update apple new update iphone update new iPhone update apple updates apple news” Now, there’s a slim chance that this can work out in your favor, but it’s not likely. You’ll increase your chances of a better ranking on Google by thinking out your description, and not just trying to take the easy route. This is an example of a good meta description: The new iOS 20.5 update introduced new features such as updated security protocols and new emojis. Here's every single feature of the new iOS update explained. The new iOS 20.5 update introduced new features such as updated security protocols and new emojis. Here's every single feature of the new iOS update explained. Notice how we have “iOS 20.5 update” and “new iOS update” in the meta description. These are keywords that we’re targeting, and putting them in the meta description will hopefully give us a leg up against other articles talking about the same thing. And that’s it! We now have a good meta description that we can be proud of. To recap, here are the important points you need to remember: To recap, here are the important points you need to remember: The meta description can’t just be buzzword after buzzword; they have to be clear and concise sentences. Try to add 2 keywords to your meta description (It’s also important to add these words into your title and throughout your article). The meta description can only be 160 characters, so don’t add unnecessary words. The meta description can’t just be buzzword after buzzword; they have to be clear and concise sentences. Try to add 2 keywords to your meta description (It’s also important to add these words into your title and throughout your article). The meta description can only be 160 characters, so don’t add unnecessary words. With these tips, and with your talent, we know your articles will shoot up in the Google stratosphere. Put your newly acquired skills to use! Use this template to let us know what everyone should know. It could be about the latest Apple update, useful coding tips, or things going on in the world around us. Put your newly acquired skills to use! Use this template to let us know what everyone should know . It could be about the latest Apple update, useful coding tips, or things going on in the world around us. everyone should know But wait. There’s More! Did you know HackerNoon is always running writing contests where the winning writers can earn money?? Here are the 5 we currently have going on: writing contests The #blockchain-api Writing Contest by dRPC ($1,000 in total prizes) The #bitcoin Writing Contest by Rootstock ($17,500 in total prizes) The Opt-Out Writing Contest by Āut Labs (9,000 USDT in total prizes) The #crypto-api Writing Contest by CoinGecko ($1,000 in total prizes) The #decentralize-ai Writing Contest by ICP ($1,000 in total prizes) The #ethereum Writing Contest by DeGate ($1,000 in total prizes) The #blockchain-api Writing Contest by dRPC ($1,000 in total prizes) The #blockchain-api Writing Contest by dRPC The #blockchain-api Writing Contest by dRPC The #bitcoin Writing Contest by Rootstock ($17,500 in total prizes) The #bitcoin Writing Contest by Rootstock The #bitcoin Writing Contest by Rootstock The Opt-Out Writing Contest by Āut Labs (9,000 USDT in total prizes) The Opt-Out Writing Contest by Āut Labs The Opt-Out Writing Contest by Āut Labs The #crypto-api Writing Contest by CoinGecko ($1,000 in total prizes) The #crypto-api Writing Contest by CoinGecko The #crypto-api #crypto-api Writing Contest by CoinGecko The #decentralize-ai Writing Contest by ICP ($1,000 in total prizes) The #decentralize-ai Writing Contest by ICP The #ethereum Writing Contest by DeGate ($1,000 in total prizes) The #ethereum Writing Contest by DeGate See you next time!

Get on Google's Front Page with Effective Meta Descriptions: Insider Tips from HackerNoon Editors

কার্যকরী মেটা বর্ণনা সহ Google এর সামনের পৃষ্ঠায় যান: হ্যাকারনুন সম্পাদকদের কাছ থেকে অভ্যন্তরীণ টিপস

Mit effektiven Meta-Beschreibungen auf die erste Seite von Google gelangen: Insider-Tipps der HackerNoon-Redakteure

Acceda a la página principal de Google con metadescripciones efectivas: consejos de expertos de los editores de HackerNoon

Accédez à la première page de Google avec des méta descriptions efficaces : conseils d'initiés des éditeurs de HackerNoon

प्रभावी मेटा विवरण के साथ Google के फ्रंट पेज पर आएं: HackerNoon संपादकों से अंदरूनी सुझाव

効果的なメタディスクリプションで Google のトップページに掲載される: HackerNoon 編集者からのヒント

효과적인 메타 설명으로 Google의 첫 페이지에 등장: HackerNoon 편집자가 전하는 내부자 팁

Entre na primeira página do Google com meta descrições eficazes: dicas internas dos editores do HackerNoon

Попадитесь на главную страницу Google с эффективными метаописаниями: советы инсайдеров от редакторов HackerNoon

Etkili Meta Açıklamalarıyla Google'ın Ön Sayfasına Çıkın: HackerNoon Editörlerinden İçeriden İpuçları

Lên Trang nhất của Google với Mô tả Meta hiệu quả: Lời khuyên nội bộ từ Biên tập viên HackerNoon

利用有效的元描述登上 Google 首页：来自 HackerNoon 编辑的内部提示

The Declining Critical Thinking Skills: From Artificial Intelligence to Average Intelligence

Singularity: Streamlining Game Development with a Universal Backend Framework

এককতা: একটি ইউনিভার্সাল ব্যাকএন্ড ফ্রেমওয়ার্ক সহ গেম ডেভেলপমেন্টকে স্ট্রীমলাইন করা

Singularity: Optimierte Spieleentwicklung mit einem universellen Backend-Framework

Singularidad: agilización del desarrollo de juegos con un marco de backend universal

Singularity : rationaliser le développement de jeux avec un framework backend universel

सिंगलेरिटी: यूनिवर्सल बैकएंड फ्रेमवर्क के साथ गेम डेवलपमेंट को सुव्यवस्थित करना

Singularity: ユニバーサル バックエンド フレームワークによるゲーム開発の効率化

Singularity: 범용 백엔드 프레임워크로 게임 개발 간소화

Singularidade: simplificando o desenvolvimento de jogos com uma estrutura de back-end universal

Singularity: оптимизация разработки игр с помощью универсальной серверной платформы

Tekillik: Evrensel Arka Uç Çerçevesiyle Oyun Geliştirmeyi Kolaylaştırma

Điểm kỳ dị: Hợp lý hóa quá trình phát triển trò chơi với Khung phụ trợ phổ quát

Singularity：使用通用后端框架简化游戏开发

In May 2024, Google rolled out its AI Overview feature to enhance users’ experiences in the search engine. This latest feature was intended to streamline searching by summarizing information from multiple sources. The answers it provides are typically concisely written responses to queries that people enter in the search bar. With this new AI Overview, Google’s intentions were clear — to leverage advanced AI to make search faster and more reliable. However, the reality of the AI Overview’s performance has fallen short of expectations in the months since its release. Almost immediately after its launch, users began encountering some unexpected issues. Social media and community forums buzzed with examples of the AI Overview producing absurd recommendations. Some of its responses even provided dangerous advice to users. Among the most viral incidents was the suggestion to use ⅛ cup of nontoxic glue on pizza to help the cheese stick. People eventually discovered this recommendation was pulled from an old, satirical post on Reddit. Now, they are expressing their opinions and concerns on the internet about how Google was too quick to launch AI Overview. What Users Think of Google’s AI Overview Now, nearly two months after its release, user reactions to Google’s AI Overview still vary. Some people love it, while others express dissatisfaction. A HackerNoon poll found that 29% said they hated the feature and would prefer Google to get rid of it. Meanwhile, another 29% disliked it for now but believe Google could make some improvements. Reddit users have been vocal about AI Overview's shortcomings and poor advice. From eating a rock a day to incorrect cooking temperatures, the errors have led to widespread criticism of Google. A Reddit thread in the r/technology community discussed these issues extensively. Users expressed frustration over the feature, pointing out that it does not know the difference between humor and authentic content. Some people even mentioned that AI Overview was never a good idea in the first place. On the other hand, some people come to Google’s defense by explaining how LLMs work and the reasoning behind some of the inaccurate information they provide. Despite the backlash, some users see potential in the technology. Some believe it is valuable but needs some refinements. Google’s Thoughts on the Matter When people read about how poor some of the responses from the overviews are, they wonder whether Google truly considered how its audience would use its products. After all, 60% of online users consider trustworthiness a top priority when using a brand’s products — meaning providing trustworthy answers should have been the number one priority. However, it seems Google skipped over the testing part and launched its AI Overview without question. Google has admitted to the search feature’s errors. In a blog post, Google’s head of search, Liz Reid, stated that she saw AI Overview feature sarcastic and satirical content. While she finds public forums to be the best source of authentic information, Reid suggested that AI Overview can lead to some unhelpful advice. However, Google also claims some screenshots of AI Overviews with nonsensical responses may be fake. WIRED has even conducted its own testing to determine if this is true. It found that one screenshot with over 5 million views did not align with how AI Overview presents information to users. Still, Google realizes that AI Overviews prevent users from experiencing its full potential. That is why it has made over a dozen improvements, including enhancing the detection of queries that do not call for an AI Overview. Google also intends to keep a close eye on the tool and adjust its features according to user feedback. The Implications of the State of AI AI has proven to be a helpful tool for many, but some of the issues it presents clearly indicate that it still needs to improve. The overall takeaways about the state of AI involve a few things to keep in mind. 1. AI Relies Too Heavily on Biased Datasets AI systems are only as good as the data they are trained on, presenting a large problem for bias. When machine learning engineers feed these datasets to AI systems, they often contain bias from decades of content. As a result, LLMs will replicate these biases and open the possibility of perpetuating existing misinformation. For instance, if an AI system frequently sources data from platforms known for low-quality content, it can propagate false information. Addressing these biases requires a larger effort to curate diverse and high-quality datasets. Additionally, mechanisms should be established to detect and mitigate bias in AI training processes. 2. AI Lacks Contextual Awareness and Advanced Reasoning While AI can process data quickly, it often fails to understand nuances to provide deeper context. A great example is when Google’s AI Overview misinterpreted information from a travel blog post about slot canyons near Las Vegas. It confused them with normal canyons, not even knowing their differences. This mistake can confuse some people, showing AI’s limitations in understanding and reasoning contextually. Such errors diminish user trust and highlight the need for more sophisticated AI systems to accurately grasp and analyze context. 3. AI Acts as a People Pleaser One of the more troubling aspects of AI systems is their propensity to generate a response for every query. Even if they cannot provide a sensible answer, they will still create a response. This eagerness to please often leads to the machine fabricating information or presenting incorrect data confidently. As such, it provides misleading advice that can spread from one person to the next. AI Overview has had several cases where it offered advice based on satirical content or outdated sources simply because it was compelled to provide an answer. With this tendency comes the necessity to recognize AI’s limitations and refrain from asking it further questions when it cannot answer accurately. 4. AI Is Limited on Data Another clear issue is the constraints of the datasets on which they are trained. With a fixed cutoff date, AI can quickly become obsolete and provide responses that are no longer relevant or accurate. This is especially problematic in a rapidly changing world. As technology, medicine and global events evolve, AI’s outdated information can lead to significant errors in its answers. AI would need constant updates to keep information fresh. However, this is a large undertaking because the process must always start from scratch. Yet, AI's reliability diminishes without such updates, making it imperative to address this issue. Dealing With AI Weaknesses The recent launch of Google’s AI Overview provides insightful information on the current state of AI and its limitations. However, as AI evolves, users may begin to see it as a more trustworthy tool. Nonetheless, it is quite clear that these tools need serious updates to end people’s complaints. It may take some time before significant advancements are made, but it will be interesting to see what AI's future has in store. In May 2024, Google rolled out its AI Overview feature to enhance users’ experiences in the search engine. This latest feature was intended to streamline searching by summarizing information from multiple sources. The answers it provides are typically concisely written responses to queries that people enter in the search bar. With this new AI Overview, Google’s intentions were clear — to leverage advanced AI to make search faster and more reliable. However, the reality of the AI Overview’s performance has fallen short of expectations in the months since its release. Almost immediately after its launch, users began encountering some unexpected issues. Social media and community forums buzzed with examples of the AI Overview producing absurd recommendations. Some of its responses even provided dangerous advice to users. Among the most viral incidents was the suggestion to use ⅛ cup of nontoxic glue on pizza to help the cheese stick. People eventually discovered this recommendation was pulled from an old, satirical post on Reddit. Now, they are expressing their opinions and concerns on the internet about how Google was too quick to launch AI Overview. use ⅛ cup of nontoxic glue on pizza What Users Think of Google’s AI Overview Now, nearly two months after its release, user reactions to Google’s AI Overview still vary. Some people love it, while others express dissatisfaction. A HackerNoon poll found that 29% said they hated the feature and would prefer Google to get rid of it. Meanwhile, another 29% disliked it for now but believe Google could make some improvements. 29% said they hated the feature Reddit users have been vocal about AI Overview's shortcomings and poor advice. From eating a rock a day to incorrect cooking temperatures, the errors have led to widespread criticism of Google. Reddit A Reddit thread in the r/technology community discussed these issues extensively. Users expressed frustration over the feature, pointing out that it does not know the difference between humor and authentic content. Some people even mentioned that AI Overview was never a good idea in the first place. thread in the r/technology community On the other hand, some people come to Google’s defense by explaining how LLMs work and the reasoning behind some of the inaccurate information they provide. Despite the backlash, some users see potential in the technology. Some believe it is valuable but needs some refinements. Google’s Thoughts on the Matter When people read about how poor some of the responses from the overviews are, they wonder whether Google truly considered how its audience would use its products. After all, 60% of online users consider trustworthiness a top priority when using a brand’s products — meaning providing trustworthy answers should have been the number one priority. However, it seems Google skipped over the testing part and launched its AI Overview without question. 60% of online users consider trustworthiness Google has admitted to the search feature’s errors. In a blog post, Google’s head of search, Liz Reid, stated that she saw AI Overview feature sarcastic and satirical content. While she finds public forums to be the best source of authentic information, Reid suggested that AI Overview can lead to some unhelpful advice. However, Google also claims some screenshots of AI Overviews with nonsensical responses may be fake. WIRED has even conducted its own testing to determine if this is true. It found that one screenshot with over 5 million views did not align with how AI Overview presents information to users. one screenshot with over 5 million views Still, Google realizes that AI Overviews prevent users from experiencing its full potential. That is why it has made over a dozen improvements, including enhancing the detection of queries that do not call for an AI Overview. Google also intends to keep a close eye on the tool and adjust its features according to user feedback. The Implications of the State of AI AI has proven to be a helpful tool for many, but some of the issues it presents clearly indicate that it still needs to improve. The overall takeaways about the state of AI involve a few things to keep in mind. 1. AI Relies Too Heavily on Biased Datasets AI systems are only as good as the data they are trained on, presenting a large problem for bias. When machine learning engineers feed these datasets to AI systems, they often contain bias from decades of content. As a result, LLMs will replicate these biases and open the possibility of perpetuating existing misinformation. For instance, if an AI system frequently sources data from platforms known for low-quality content, it can propagate false information. Addressing these biases requires a larger effort to curate diverse and high-quality datasets. Additionally, mechanisms should be established to detect and mitigate bias in AI training processes. 2. AI Lacks Contextual Awareness and Advanced Reasoning While AI can process data quickly, it often fails to understand nuances to provide deeper context. A great example is when Google’s AI Overview misinterpreted information from a travel blog post about slot canyons near Las Vegas. It confused them with normal canyons, not even knowing their differences. misinterpreted information from a travel blog post This mistake can confuse some people, showing AI’s limitations in understanding and reasoning contextually. Such errors diminish user trust and highlight the need for more sophisticated AI systems to accurately grasp and analyze context. 3. AI Acts as a People Pleaser One of the more troubling aspects of AI systems is their propensity to generate a response for every query. Even if they cannot provide a sensible answer, they will still create a response. This eagerness to please often leads to the machine fabricating information or presenting incorrect data confidently. As such, it provides misleading advice that can spread from one person to the next. AI Overview has had several cases where it offered advice based on satirical content or outdated sources simply because it was compelled to provide an answer. With this tendency comes the necessity to recognize AI’s limitations and refrain from asking it further questions when it cannot answer accurately. 4. AI Is Limited on Data Another clear issue is the constraints of the datasets on which they are trained. With a fixed cutoff date, AI can quickly become obsolete and provide responses that are no longer relevant or accurate. This is especially problematic in a rapidly changing world. As technology, medicine and global events evolve, AI’s outdated information can lead to significant errors in its answers. AI would need constant updates to keep information fresh. However, this is a large undertaking because the process must always start from scratch. Yet, AI's reliability diminishes without such updates, making it imperative to address this issue. Dealing With AI Weaknesses The recent launch of Google’s AI Overview provides insightful information on the current state of AI and its limitations. However, as AI evolves, users may begin to see it as a more trustworthy tool. Nonetheless, it is quite clear that these tools need serious updates to end people’s complaints. It may take some time before significant advancements are made, but it will be interesting to see what AI's future has in store.

What We Can Learn About the State of AI From Google’s AI Overview Launch

In my previous article, Managing Architectural Tech Debt, I talked about understanding and managing architectural technical debt. Architectural technical debt is the often ignored, but ironically, one of the most damaging, categories of technical debt. In this article, I want to dive deeper into one way to manage architectural technical debt (and technical debt as a whole)—architectural observability (AO). AO is a new category of observability that I believe is just as important, if not more so, as application performance management (APM). I believe we need to shift left observability—to the architectural stage—where we can not just see symptoms, but fix core problems. Let’s take a look. APM Is (Half) the Answer You already know that APM is important. Gartner defines it as “software that enables the observation and analysis of application health, performance and user experience.” And IDC reports that companies using APM solutions see a 2.5x improvement in mean time to resolution (MTTR) and a 50% reduction in the number of incidents. APM and observability: Helps to ensure better user experiences by monitoring, in real-time, performance and responsiveness.
Can help identify defects.
Can provide data to teams, such as usage patterns, bottlenecks, and overall health to keep systems healthy. Overall, APM has become a necessary tool for troubleshooting and fixing issues in enterprise environments. APM has become table stakes. And APM works! In my current role, we use APM to observe the usage of our APIs to understand the breakdown of URI (uniform resource identifier) requests across all of our consumers. When our APIs are not functioning as expected, we lean to APM in order to gain visibility into performance bottlenecks. In cases where an alert is triggered, the same interface can be utilized for initial troubleshooting efforts in order to help pin down the root cause. But even though APM works, there’s a problem. APM identifies the symptoms of the defects, but not the actual defects themselves. It’s up to the team to track down why the problems are occurring. And with the pressure we often feel in prod to “just fix the problem as fast as you can,” I often see that while symptoms may be addressed, teams don’t have the time (or organizational support) to find and fix the actual core problems. Imagine taking aspirin because you get a headache every night, but never taking the time to figure out why you keep having headaches. To find—and address—the why of our defects, we need architectural observability. Architectural Observability: Getting to the Real Answers We need to shift our processes left, stop focusing on symptoms, and instead focus on the root cause of these problems and actually reduce the number of incidents caught with APM. That’s where architectural observability comes in. Architectural observability is the ability to analyze an application’s architecture (both statically and dynamically), understand how it works, observe changes, and identify and fix architectural technical debt. Architectural observability is the next step in observability tools. Architectural observability gives you visibility into your application architecture, helping you solve problems (not just identify symptoms) earlier in the SDLC by identifying architectural issues. You probably already have the data you need to implement AO—it uses the same data sources as APM (for example, OpenTelemetry (OTel). But AO takes that data and applies a layer of intelligence that focuses on analyzing the architecture and the sources of architectural technical debt. For example, an AO tool might analyze: Architectural complexity - The interdependence and relationships of services within the architecture, the number of flows in a service, identifying multi-hop flows and circular flows. Dependency mappings - Relationships among services including circular dependencies. Architectural drift - What has changed since your last release, what new domains/services were added, what new dependencies and flows were introduced. Technical debt - Such as resource exclusivity, service dependencies, duplicate services that should be merged, and complexity. Technical debt is a huge problem in the industry. 70% of organizations say that technical debt is a major obstacle to innovation. Database-related issues - Examine if multiple services are accessing tables. Architectural observability is proactive and strategic. Where APM tools alert on the leaks in the roof when it is already raining, AO identifies architectural issues that can lead to those leaks, way before they actually occur. Using Tools to Gain Architectural Observability Used well, AO doesn’t just help you find issues earlier, but helps you: Truly discover and understand your architecture and its relationships and dependencies.
Prevent issues caused by architectural changes.
Make systems more resilient and scalable by continually monitoring, modernizing, and strengthening your architecture.
Minimize technical debt. I love that last one. As I pointed out in my last article, architectural debt is a foe of mine that I have been battling for over a decade. Architectural observability is a new field and is starting to gain traction as something teams must have. There aren’t many tools yet built around the concept, but let’s look at how your team might use one of the first AO tools—vFunction—to gain AO. Once you’ve connected to your applications (through the OTel connector or similar), the tool analyzes your system (in this case with vFunction, it’s using AI to understand and analyze your architecture). Then you get a report on the current state of your architecture. You’ll see details such as: A visualization of the architecture across your entire app portfolio
A map of services and entry points, cross services APIs, and external APIs
Exclusivity of database tables (Kafka, Redis, MongoDB) and other resources
Complexity scores
And more… And you can use architectural observability to monitor your architecture not just in the present state, but dynamically as it changes. Changes to your architecture (a.k.a., architectural drift)? You’ll know right away.
Add a dependency impacting resiliency? You’ll catch it before migrating.
Did you create a circular flow? Did you significantly increase the complexity of your system? Find out early. Incurring even more technical debt? You can’t hide from it now. With architectural observability, you now have hard proof of how architectural debt is affecting your systems and how, by using AO, you can identify and prioritize the actual problems in your systems early and often, rather than only addressing the symptoms in production. AO makes applications more resilient, more scalable, and helps your team move faster. And AO can help proactively. Is your team moving from a monolith to a microservice? AO can give you a plan to move your architecture forward. With AO, you could analyze your monolith, understand how its domains and functionality are structured and connected, and then get actionable steps on how to modularize and move the functionality to microservices. And once you have a distributed architecture (microservices or distributed monoliths), you’ll want to make sure your architecture doesn’t drift or get more complex to the point that things start to break, you lose control, and you have to slow down your engineering velocity. AO keeps your applications in check whether monolith or microservices. Architectural Observability Gives You Better Systems My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester Architectural observability adheres to my mission statement perfectly. By moving from plain vanilla observability to architectural observability, we can shift left for more reliable, more resilient, and better-performing systems. This shift affords us more time to spend on the business problems that our teams understand best. As John F. Kennedy once said: “The best time to repair the roof is when the sun is shining.” Architectural observability should be placed on the same level (or higher) as APM. With AO, teams can truly understand their architecture, have a broader and more insightful view of their applications than with APM alone, and fix problems earlier. Have a really great day! In my previous article, Managing Architectural Tech Debt , I talked about understanding and managing architectural technical debt. Architectural technical debt is the often ignored, but ironically, one of the most damaging , categories of technical debt. Managing Architectural Tech Debt architectural the most damaging In this article, I want to dive deeper into one way to manage architectural technical debt (and technical debt as a whole)— architectural observability (AO) . AO is a new category of observability that I believe is just as important, if not more so, as application performance management (APM). I believe we need to shift left observability—to the architectural stage—where we can not just see symptoms, but fix core problems. architectural observability (AO) Let’s take a look. APM Is (Half) the Answer You already know that APM is important. Gartner defines it as “software that enables the observation and analysis of application health, performance and user experience.” And IDC reports that companies using APM solutions see a 2.5x improvement in mean time to resolution (MTTR) and a 50% reduction in the number of incidents. IDC reports APM and observability: Helps to ensure better user experiences by monitoring, in real-time, performance and responsiveness. Can help identify defects. Can provide data to teams, such as usage patterns, bottlenecks, and overall health to keep systems healthy. Helps to ensure better user experiences by monitoring, in real-time, performance and responsiveness. Can help identify defects. Can provide data to teams, such as usage patterns, bottlenecks, and overall health to keep systems healthy. Overall, APM has become a necessary tool for troubleshooting and fixing issues in enterprise environments. APM has become table stakes. And APM works! In my current role, we use APM to observe the usage of our APIs to understand the breakdown of URI (uniform resource identifier) requests across all of our consumers. When our APIs are not functioning as expected, we lean to APM in order to gain visibility into performance bottlenecks. In cases where an alert is triggered, the same interface can be utilized for initial troubleshooting efforts in order to help pin down the root cause. But even though APM works, there’s a problem. APM identifies the symptoms of the defects, but not the actual defects themselves . It’s up to the team to track down why the problems are occurring. And with the pressure we often feel in prod to “just fix the problem as fast as you can,” I often see that while symptoms may be addressed, teams don’t have the time (or organizational support) to find and fix the actual core problems. but not the actual defects themselves why Imagine taking aspirin because you get a headache every night, but never taking the time to figure out why you keep having headaches. To find—and address—the why of our defects, we need architectural observability . why architectural observability Architectural Observability: Getting to the Real Answers We need to shift our processes left, stop focusing on symptoms, and instead focus on the root cause of these problems and actually reduce the number of incidents caught with APM. root cause of these problems That’s where architectural observability comes in. Architectural observability is the ability to analyze an application’s architecture (both statically and dynamically), understand how it works, observe changes, and identify and fix architectural technical debt. Architectural observability Architectural observability is the next step in observability tools. Architectural observability gives you visibility into your application architecture, helping you solve problems (not just identify symptoms) earlier in the SDLC by identifying architectural issues. You probably already have the data you need to implement AO—it uses the same data sources as APM (for example, OpenTelemetry (OTel). But AO takes that data and applies a layer of intelligence that focuses on analyzing the architecture and the sources of architectural technical debt. For example, an AO tool might analyze: Architectural complexity - The interdependence and relationships of services within the architecture, the number of flows in a service, identifying multi-hop flows and circular flows. Architectural complexity - The interdependence and relationships of services within the architecture, the number of flows in a service, identifying multi-hop flows and circular flows. Architectural complexity Dependency mappings - Relationships among services including circular dependencies. Dependency mappings - Relationships among services including circular dependencies. Dependency mappings Architectural drift - What has changed since your last release, what new domains/services were added, what new dependencies and flows were introduced. Architectural drift - What has changed since your last release, what new domains/services were added, what new dependencies and flows were introduced. Architectural drift Technical debt - Such as resource exclusivity, service dependencies, duplicate services that should be merged, and complexity. Technical debt is a huge problem in the industry. 70% of organizations say that technical debt is a major obstacle to innovation. Technical debt - Such as resource exclusivity, service dependencies, duplicate services that should be merged, and complexity. Technical debt is a huge problem in the industry. 70% of organizations say that technical debt is a major obstacle to innovation. Technical debt major obstacle to innovation. Database-related issues - Examine if multiple services are accessing tables. Database-related issues - Examine if multiple services are accessing tables. Database-related issues Architectural observability is proactive and strategic. Where APM tools alert on the leaks in the roof when it is already raining, AO identifies architectural issues that can lead to those leaks, way before they actually occur. Using Tools to Gain Architectural Observability Used well, AO doesn’t just help you find issues earlier, but helps you: Truly discover and understand your architecture and its relationships and dependencies. Prevent issues caused by architectural changes. Make systems more resilient and scalable by continually monitoring, modernizing, and strengthening your architecture. Minimize technical debt. Truly discover and understand your architecture and its relationships and dependencies. Prevent issues caused by architectural changes. Prevent Make systems more resilient and scalable by continually monitoring, modernizing, and strengthening your architecture. Minimize technical debt. I love that last one. As I pointed out in my last article , architectural debt is a foe of mine that I have been battling for over a decade. my last article Architectural observability is a new field and is starting to gain traction as something teams must have. There aren’t many tools yet built around the concept, but let’s look at how your team might use one of the first AO tools—vFunction—to gain AO. Once you’ve connected to your applications (through the OTel connector or similar), the tool analyzes your system (in this case with vFunction, it’s using AI to understand and analyze your architecture). Then you get a report on the current state of your architecture. You’ll see details such as: A visualization of the architecture across your entire app portfolio A map of services and entry points, cross services APIs, and external APIs Exclusivity of database tables (Kafka, Redis, MongoDB) and other resources Complexity scores And more… A visualization of the architecture across your entire app portfolio A map of services and entry points, cross services APIs, and external APIs Exclusivity of database tables (Kafka, Redis, MongoDB) and other resources Complexity scores And more… And you can use architectural observability to monitor your architecture not just in the present state, but dynamically as it changes. Changes to your architecture (a.k.a., architectural drift)? You’ll know right away. Add a dependency impacting resiliency? You’ll catch it before migrating. Did you create a circular flow? Did you significantly increase the complexity of your system? Find out early. Changes to your architecture (a.k.a., architectural drift)? You’ll know right away. Add a dependency impacting resiliency? You’ll catch it before migrating. Did you create a circular flow? Did you significantly increase the complexity of your system? Find out early. Incurring even more technical debt? You can’t hide from it now. more With architectural observability, you now have hard proof of how architectural debt is affecting your systems and how, by using AO, you can identify and prioritize the actual problems in your systems early and often, rather than only addressing the symptoms in production. AO makes applications more resilient, more scalable, and helps your team move faster. And AO can help proactively. Is your team moving from a monolith to a microservice? AO can give you a plan to move your architecture forward. With AO, you could analyze your monolith, understand how its domains and functionality are structured and connected, and then get actionable steps on how to modularize and move the functionality to microservices. And once you have a distributed architecture (microservices or distributed monoliths), you’ll want to make sure your architecture doesn’t drift or get more complex to the point that things start to break, you lose control, and you have to slow down your engineering velocity. AO keeps your applications in check whether monolith or microservices. Architectural Observability Gives You Better Systems My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester Architectural observability adheres to my mission statement perfectly. By moving from plain vanilla observability to architectural observability , we can shift left for more reliable, more resilient, and better-performing systems. This shift affords us more time to spend on the business problems that our teams understand best. architectural observability As John F. Kennedy once said: “The best time to repair the roof is when the sun is shining.” Architectural observability should be placed on the same level (or higher) as APM. With AO, teams can truly understand their architecture, have a broader and more insightful view of their applications than with APM alone, and fix problems earlier. Have a really great day!

From Observability to Architectural Observability—Shifting Left for Resiliency

Empowerment is widely endorsed. There is consensus that top management should trust teams to solve problems and provide them with the autonomy to achieve goals and milestones. This trust is not just a formality but a recognition of the value and expertise that teams bring to the table. However, the challenge lies in transitioning teams from a feature-factory mentality to a value-driven approach. Development teams often need to prepare for such a shift to gain experience in taking on this level of responsibility. Let's face it: being accountable for outcomes is much more complex than simply delivering fixed tasks with specific features. Despite the increased risk associated with focusing on outcomes, it is far more interesting and exciting for everyone involved. Remember when time used to go much slower when we were kids? Scientists say that is because we explore the world and learn something new daily. Here are some strategies to effectively transition from focusing solely on output to achieving meaningful outcomes. Overcome the feature-centric mindset once and for all. Mindset Difference. For a long time, success was delivering features within deadlines and scope. I excelled at meeting stakeholders’ wants. They were happy with the results, and we were comfortable with how we worked. There was no room for confusion. Everyone understood their tasks and deadlines without problem. Every Sprint followed a similar pattern: features, features, features, a bug fix here and a refactor there, but nothing more. Our primary responsibility was to deliver outputs on time, a task we were adept at fulfilling. However, with the restructuring of the leadership team, expectations shifted. They emphasised achieving goals rather than dictating specific tasks. When they stopped telling us what to do, we panicked. We needed guidance as to where even to start. The questions running through our minds were: Where should we start?
What if we make a wrong decision? Will we be held accountable?
How do we define success now? It was embarrassing. We wanted responsibility and autonomy, and that’s exactly what we got. The real challenge, however, lay in figuring out how to deal with it. We were empowered to achieve goals but needed to prepare for the task. Output vs Outcome. Until then, we had solely concentrated on outputs, completely unaware of the true essence of outcomes. Let’s try to summarise the difference. An output is created for customers to use, such as product recommendations in the e-commerce industry. These recommendations are designed to deliver value. Their outcomes assess the effectiveness of outputs. For instance, when customers add recommended products to their carts, increasing sales represents an outcome. Now, here's the exciting part: Various outputs can achieve outcomes. It's like solving a problem where multiple alternatives exist. When you begin with the outcome in mind, you unlock diverse possibilities and increase your chances of creating significant value. Start small. Getting someone who is already an expert on the topic will make your life much easier. To get where you’ve never been, seek guidance from someone already there! I froze when I first faced true empowerment, and so did everyone else. Despite our attempts to shift focus towards outcomes, our lack of experience inevitably led to failure, as anticipated. We struggled with conducting discovery experiments;
Developers expected precise requirements from me as usual, and;
Stakeholders prioritised feature predictability; The dynamics began to shift when an experienced person joined our team. Instead of overhauling everything at once, we transitioned gradually from focusing on outputs to emphasising outcomes. Our Sprints primarily focused on delivering outputs, with some items oriented towards achieving outcomes. This mixed approach allowed us to change to a new working method gradually. For instance, in one Sprint, we allocated approximately 70% of our capacity to completing a pre-defined integration with partners and 20% to exploring methods to reduce our churn rate. Through this process, we discovered the barriers preventing us from fully embracing the unknown: We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines;
We avoided exploring alternative solutions, fearing the prospect of failure and criticism;
The uncertainty of the unknown made us uneasy as it challenged our accustomed security; Gradually, however, clarity emerged, and we began transforming our work approach. Mindset transformation is required. Transitioning from focusing on output to prioritising outcome is challenging and demanding, as it upends everything you thought you knew about your work methods. With an output mindset, decisions typically revolve around how to deliver predefined features. When a value-driven mindset with a focus on outcomes is an adapter, you need to make decisions frequently—some say even 10 times as many. You must choose problems to solve, find solutions, test them, inspect them, and adapt. It’s more demanding, without a doubt. It also means that you are still working when customers receive the functionality. It is crucial to understand how it works, what they like, how to improve, and how to measure the outcome. So what can help: Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager;
Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions;
Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste;
Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset; Once you've shifted your mindset to focus on outcomes, the orientation towards achieving meaningful results becomes motivating and inspiring. Every Sprint becomes a different story. So What? Moving from output to outcome is stressful. The burden on your shoulders will be heavy, but you’ll never learn so many new things. Scrum teams yearn for empowerment but can feel overwhelmed when it arrives. Navigate this shift with guidance from experienced mentors and embrace gradual progress. Remember, it's a marathon, not a sprint. Prioritise moving in the right direction over rushing against time. Empowerment is widely endorsed. There is consensus that top management should trust teams to solve problems and provide them with the autonomy to achieve goals and milestones. This trust is not just a formality but a recognition of the value and expertise that teams bring to the table. However, the challenge lies in transitioning teams from a feature-factory mentality to a value-driven approach. Development teams often need to prepare for such a shift to gain experience in taking on this level of responsibility. Let's face it: being accountable for outcomes is much more complex than simply delivering fixed tasks with specific features. Despite the increased risk associated with focusing on outcomes, it is far more interesting and exciting for everyone involved. Remember when time used to go much slower when we were kids? Scientists say that is because we explore the world and learn something new daily. Here are some strategies to effectively transition from focusing solely on output to achieving meaningful outcomes. Overcome the feature-centric mindset once and for all. Mindset Difference. For a long time, success was delivering features within deadlines and scope. I excelled at meeting stakeholders’ wants. They were happy with the results, and we were comfortable with how we worked. There was no room for confusion. Everyone understood their tasks and deadlines without problem. Every Sprint followed a similar pattern: features, features, features, a bug fix here and a refactor there, but nothing more. Our primary responsibility was to deliver outputs on time, a task we were adept at fulfilling. However, with the restructuring of the leadership team, expectations shifted. They emphasised achieving goals rather than dictating specific tasks. When they stopped telling us what to do, we panicked. We needed guidance as to where even to start. The questions running through our minds were: Where should we start? What if we make a wrong decision? Will we be held accountable? How do we define success now? Where should we start? What if we make a wrong decision? Will we be held accountable? How do we define success now? It was embarrassing. We wanted responsibility and autonomy, and that’s exactly what we got. The real challenge, however, lay in figuring out how to deal with it. We were empowered to achieve goals but needed to prepare for the task. Output vs Outcome. Until then, we had solely concentrated on outputs, completely unaware of the true essence of outcomes. Let’s try to summarise the difference. An output is created for customers to use, such as product recommendations in the e-commerce industry. These recommendations are designed to deliver value. Their outcomes assess the effectiveness of outputs. For instance, when customers add recommended products to their carts, increasing sales represents an outcome. Now, here's the exciting part: Various outputs can achieve outcomes. It's like solving a problem where multiple alternatives exist. When you begin with the outcome in mind, you unlock diverse possibilities and increase your chances of creating significant value. Start small. Getting someone who is already an expert on the topic will make your life much easier. To get where you’ve never been, seek guidance from someone already there! I froze when I first faced true empowerment, and so did everyone else. Despite our attempts to shift focus towards outcomes, our lack of experience inevitably led to failure, as anticipated. We struggled with conducting discovery experiments; Developers expected precise requirements from me as usual, and; Stakeholders prioritised feature predictability; We struggled with conducting discovery experiments; Developers expected precise requirements from me as usual, and; Stakeholders prioritised feature predictability; The dynamics began to shift when an experienced person joined our team. Instead of overhauling everything at once, we transitioned gradually from focusing on outputs to emphasising outcomes. Our Sprints primarily focused on delivering outputs, with some items oriented towards achieving outcomes. This mixed approach allowed us to change to a new working method gradually. For instance, in one Sprint, we allocated approximately 70% of our capacity to completing a pre-defined integration with partners and 20% to exploring methods to reduce our churn rate. Through this process, we discovered the barriers preventing us from fully embracing the unknown: We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines; We avoided exploring alternative solutions, fearing the prospect of failure and criticism; The uncertainty of the unknown made us uneasy as it challenged our accustomed security; We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines; We avoided exploring alternative solutions, fearing the prospect of failure and criticism; The uncertainty of the unknown made us uneasy as it challenged our accustomed security; Gradually, however, clarity emerged, and we began transforming our work approach. Mindset transformation is required. Transitioning from focusing on output to prioritising outcome is challenging and demanding, as it upends everything you thought you knew about your work methods. With an output mindset, decisions typically revolve around how to deliver predefined features. When a value-driven mindset with a focus on outcomes is an adapter, you need to make decisions frequently—some say even 10 times as many. You must choose problems to solve, find solutions, test them, inspect them, and adapt. It’s more demanding, without a doubt. It also means that you are still working when customers receive the functionality. It is crucial to understand how it works, what they like, how to improve, and how to measure the outcome. So what can help: Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager; Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions; Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste; Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset; Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager; Coaching: Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions; Problems over solutions: Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste; Learning over predictability: Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset; Evidence over opinions: Once you've shifted your mindset to focus on outcomes, the orientation towards achieving meaningful results becomes motivating and inspiring. Every Sprint becomes a different story. So What? Moving from output to outcome is stressful. The burden on your shoulders will be heavy, but you’ll never learn so many new things. Scrum teams yearn for empowerment but can feel overwhelmed when it arrives. Navigate this shift with guidance from experienced mentors and embrace gradual progress. Remember, it's a marathon, not a sprint. Prioritise moving in the right direction over rushing against time.

From Outputs to Outcomes

COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 20 of 42. 18. “ESDT.tex” {ID_004736} {PTR-F/93/1} 340. The document is a LaTeX source presented as if it was precursor work to the Bitcoin White Paper created during Dr Wright’s employment at BDO. Dr Wright relies upon it as a draft addressing technical concepts which influenced his development of Bitcoin. By its presence in BDOPC.raw, the document purports to pre-date 31 October 2007. (a) COPA’s Reasons for Alleging Forgery 341. This document is among the 71 New Reliance Documents that were inserted into the BDO Drive by the editing process and which the parties’ experts agree were manipulated [Madden / Lynch1 [12] Q/6/5]. 342. Copies of the document are also located on the Samsung Drive. These copies display signs of metadata editing and clock manipulation. [PM46 [74-79] H/278/17] 343. A related LaTeX file has been recovered which encodes the same textual content in a different way. That document had been deleted but was recoverable from within the Samsung Drive. The structure of that file is consistent with the file being generated automatically by software conversion tools (rather than being authored by hand). [Madden4 [67-70] H/278/16]. 344. There is a related file {ID_004735} which appears intended to create an image for the paper. The code in that file is consistent with having been generated by conversion tools such as Aspose. [Madden3 [75] G/5/31] 345. A related document, ESDT.pdf, was recovered from the Samsung Drive. ESDT.pdf was a compiled form of {ID_004736} but was deleted and emptied from the Recycle Bin in September 2023 [PM46 [41-52] H/278/10]. The metadata associated with the deleted file indicates that it was modified on 16 September 2023, but the other timestamps have been backdated to 31 October 2007. 346. The metadata of this document (when compared with metadata of other documents related to it) displays signs of metadata editing directly using specialised metadata editing tools. [Madden3 [52-63] G/5/23] 347. The document was sourced from BDOPC.raw. The section “BDOPC.raw” above is repeated. This document was added to BDOPC.raw by the Manipulation User. (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility 348. The effect of the tampering is to make the document appear to be supportive of Dr Wright’s claim to be Satoshi Nakamoto, contrary to fact. 349. The further effect of tampering is to lend support to Dr Wright’s new position that the Bitcoin White Paper was created in LaTeX. That story is a recent product of Dr Wright’s change in his account. 350. This document was added to BDOPC.raw by the Manipulation User. The Manipulation User is Dr Wright. Paragraph 45 of the section “BDOPC.raw” above is repeated. 351. Dr Wright has attached particular importance to this document: 351.1. It is said to be among Dr Wright’s “Notes, drafts and articles addressing technical concepts that underpin the concepts developed in the Bitcoin White Paper" [Wright6 E/21/3; Schedule 1 to Field1, L20/223/4] 351.2. It is said to be important to Dr Wright’s case because it is a version of “a paper prepared for a 360º Security Summit on 15 June 2006 concerned with “Implementing Effective Risk-Based Controls”, which Dr Wright prepared in his role at BDO. The hash chain technology discussed in the paper is analogous to the blockchain technology used in Bitcoin." [Wright6 E/21/3; Schedule 1 to Field1, L20/223/5] 352. The document was not disclosed at the proper time. It was disclosed instead from the BDOPC.raw image. BDOPC.raw is not a reliable source because it has been manipulated by Dr Wright. The section “BDOPC.raw” above is repeated. (c) Dr Wright’s Explanations and COPA’s Rebuttal 353. Dr Wright claimed that his use of Xcopy had caused the load file metadata for this and two related documents to all have creation times at precisely the same time on 19 September 2017, with August 2008 accessed and modified times for this document and one other related one. He also claimed that he was still accessing files at BDO in 2008 and so that these may have been copied from a different drive: {Day5/102:21} and following. See Wright11 {CSW/2/43} for an example of him claiming how Xcopy works. 354. COPA submitted that this explanation should be rejected as dishonest for the following reasons: 354.1. If the BDOPC.raw is accepted as being forged, it follows that documents on it should be treated as being forged unless they are documents which Mr Madden says are original to the image that was taken in October 2007. 354.2. Mr Madden states that Xcopy simply does not have the effect that Dr Wright claims. This was also the view of Mr Lynch, as recorded in their Joint Report: {Q/6/4}. 354.3. Dr Wright’s excuse about accessing files at BDO in 2008 is inconsistent with his claim that the files on the BDO Drive are a time capsule and taken from a capture of the BDO files he had in 2007. 354.4. Mr Lynch agreed with Mr Madden that ID_0004736 was manipulated: {Q/6/5}. Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.

This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 20 of 42. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part of this filing here . This part is 20 of 42. HackerNoon’s Legal PDF Series HackerNoon’s Legal PDF Series here here 18. “ESDT.tex” {ID_004736} {PTR-F/93/1} 340. The document is a LaTeX source presented as if it was precursor work to the Bitcoin White Paper created during Dr Wright’s employment at BDO. Dr Wright relies upon it as a draft addressing technical concepts which influenced his development of Bitcoin. By its presence in BDOPC.raw, the document purports to pre-date 31 October 2007. (a) COPA’s Reasons for Alleging Forgery (a) COPA’s Reasons for Alleging Forgery 341. This document is among the 71 New Reliance Documents that were inserted into the BDO Drive by the editing process and which the parties’ experts agree were manipulated [Madden / Lynch1 [12] Q/6/5]. 342. Copies of the document are also located on the Samsung Drive. These copies display signs of metadata editing and clock manipulation. [PM46 [74-79] H/278/17] 343. A related LaTeX file has been recovered which encodes the same textual content in a different way. That document had been deleted but was recoverable from within the Samsung Drive. The structure of that file is consistent with the file being generated automatically by software conversion tools (rather than being authored by hand). [Madden4 [67-70] H/278/16]. 344. There is a related file {ID_004735} which appears intended to create an image for the paper. The code in that file is consistent with having been generated by conversion tools such as Aspose. [Madden3 [75] G/5/31] 345. A related document, ESDT.pdf, was recovered from the Samsung Drive. ESDT.pdf was a compiled form of {ID_004736} but was deleted and emptied from the Recycle Bin in September 2023 [PM46 [41-52] H/278/10]. The metadata associated with the deleted file indicates that it was modified on 16 September 2023, but the other timestamps have been backdated to 31 October 2007. 346. The metadata of this document (when compared with metadata of other documents related to it) displays signs of metadata editing directly using specialised metadata editing tools. [Madden3 [52-63] G/5/23] 347. The document was sourced from BDOPC.raw. The section “BDOPC.raw” above is repeated. This document was added to BDOPC.raw by the Manipulation User. (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility 348. The effect of the tampering is to make the document appear to be supportive of Dr Wright’s claim to be Satoshi Nakamoto, contrary to fact. 349. The further effect of tampering is to lend support to Dr Wright’s new position that the Bitcoin White Paper was created in LaTeX. That story is a recent product of Dr Wright’s change in his account. 350. This document was added to BDOPC.raw by the Manipulation User. The Manipulation User is Dr Wright. Paragraph 45 of the section “BDOPC.raw” above is repeated. 351. Dr Wright has attached particular importance to this document: 351.1. It is said to be among Dr Wright’s “Notes, drafts and articles addressing technical concepts that underpin the concepts developed in the Bitcoin White Paper" [Wright6 E/21/3; Schedule 1 to Field1, L20/223/4] “Notes, drafts and articles addressing technical concepts that underpin the concepts developed in the Bitcoin White Paper" 351.2. It is said to be important to Dr Wright’s case because it is a version of “a paper prepared for a 360º Security Summit on 15 June 2006 concerned with “Implementing Effective Risk-Based Controls”, which Dr Wright prepared in his role at BDO. The hash chain technology discussed in the paper is analogous to the blockchain technology used in Bitcoin." [Wright6 E/21/3; Schedule 1 to Field1, L20/223/5] “a paper prepared for a 360º Security Summit on 15 June 2006 concerned with “Implementing Effective Risk-Based Controls”, which Dr Wright prepared in his role at BDO. The hash chain technology discussed in the paper is analogous to the blockchain technology used in Bitcoin." 352. The document was not disclosed at the proper time. It was disclosed instead from the BDOPC.raw image. BDOPC.raw is not a reliable source because it has been manipulated by Dr Wright. The section “BDOPC.raw” above is repeated. (c) Dr Wright’s Explanations and COPA’s Rebuttal (c) Dr Wright’s Explanations and COPA’s Rebuttal 353. Dr Wright claimed that his use of Xcopy had caused the load file metadata for this and two related documents to all have creation times at precisely the same time on 19 September 2017, with August 2008 accessed and modified times for this document and one other related one. He also claimed that he was still accessing files at BDO in 2008 and so that these may have been copied from a different drive: {Day5/102:21} and following. See Wright11 {CSW/2/43} for an example of him claiming how Xcopy works. 354. COPA submitted that this explanation should be rejected as dishonest for the following reasons: 354.1. If the BDOPC.raw is accepted as being forged, it follows that documents on it should be treated as being forged unless they are documents which Mr Madden says are original to the image that was taken in October 2007. 354.2. Mr Madden states that Xcopy simply does not have the effect that Dr Wright claims. This was also the view of Mr Lynch, as recorded in their Joint Report: {Q/6/4}. 354.3. Dr Wright’s excuse about accessing files at BDO in 2008 is inconsistent with his claim that the files on the BDO Drive are a time capsule and taken from a capture of the BDO files he had in 2007. 354.4. Mr Lynch agreed with Mr Madden that ID_0004736 was manipulated: {Q/6/5}. Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. judiciary.uk judiciary.uk

Craig Wright’s LaTeX document "ESDT.tex" Faces Forgery Allegations from COPA

Craig Wright’s Homework Gets an F from Forensic Analysts 

COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 7 of 42. 5. “Project BlackNet” paper (Reliance Document) {ID_001379} / {L1/79/1} 100. This document purports to be a copy of a “Project BlackNet” research paper dated on its face to 3 October 2002. The document contains references to a “Stage 4 – Release Phase” and other textual amendments, referring to “Digital Cash”, as well as other features of purported relevance to Bitcoin. 101. This document includes the text of the BlackNet Abstract (see the section above) pleaded as a forgery in COPA’s Particulars of Claim [26-27], and dealt with in the preceding section. (a) COPA’s Reasons for Alleging Forgery 102. The document has been backdated [PM8 [60-61]. The document is dated on its face to 3 October 2002. However, the internal metadata for the document indicate that it was actually created on 17 February 2014. [PM8 [15]]. 103. The document is an edited version of an earlier document, into which passages of text have been inserted using text from the Bitcoin White Paper. [PM8 [23-33, 60.b.]]. 104. The document is apparently part of a series of documents, all of which carry similar content on their face, but which have been edited or are converted versions of the same file [PM8 [3]]. Some of those documents are consistent with a pattern of editing beginning with an earlier precursor document, and ending with a document which would be deployed as if it was original and authentic, in connection with Dr Wright’s claim to be Satoshi Nakamoto. See in particular Mr Madden’s discussion of {ID_001016} as another backdated document in the sequence [PM8 [34-50]]. 105. The metadata indicates that the file was created using Microsoft Word 2013 as the PDF Producer. Microsoft Word 2013 was not yet published in 2002 (the date on the face of the document) but is contemporaneous for 2014. [PM8 [15]]. 106. The document was created in PDF form by printing to PDF from an underlying precursor DOC or .DOCX document on 17 February 2014 [PM8 [16]]. No such underlying precursor document has been disclosed by Dr Wright. (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility 107. Dr Wright is listed in the metadata as the author of the document. 108. Dr Wright is listed on the face of the document as its first author. 109. Dr Wright is listed as the sole author in the ‘version control’ section of the document on page 2. 110. The document contains Dr Wright’s address and telephone number. 111. Dr Wright has positively asserted in these proceedings that this is a document on which he primarily relies as supporting his claim to be Satoshi Nakamoto. 112. The effect of the tampering is to make the document appear to be supportive of Dr Wright’s claim to be Satoshi Nakamoto (suggesting work done by him in 2002, elements of which then appeared in the Bitcoin White Paper), contrary to fact. 113. Dr Wright has posted screenshots of this document or a very similar document on Twitter, apparently in support of his claim to be Satoshi Nakamoto. 114. In his evidence in these proceedings, Dr Wright has claimed this to be a document related to the later Bitcoin White Paper and that it is original to the purported date on its face, contrary to fact. [Exhibit CSW 14]. 115. Dr Wright has relied on this document, or documents with similar content, in previous proceedings and in public in support of his claim to be Satoshi Nakamoto. 116. The metadata records “DeMorgan” as the company from which the document was created. In his evidence in these proceedings, Dr Wright relies on his work on various projects from his time at DeMorgan, as part of his claim to have been working on the concepts behind the Bitcoin White Paper. [Wright1 [32-47]]. 117. The document was created in the time zone UTC+11, consistent with Dr Wright’s location in Australia in February 2014, being the date of creation of the document. [PM8 [18]]. 118. In his Defence in these proceedings, in public social media posts, and elsewhere, Dr Wright has repeatedly stated that the series of research papers (to which this document belongs) are related to the Bitcoin White Paper, and that later applications (submitted in 2009/2010) contained the abstract of the Bitcoin White Paper. (c) Dr Wright’s Explanations and COPA’s Rebuttal 119. In Appendix B to Wright11, Dr Wright accepted that this document was created by conversion of a document to PDF format in 2014. He claimed that this document was obtained from the computer of a former employee who had achieved unauthorised access to Dr Wright’s current wife’s email account, although he did not explain why that claim was relevant. He gave no coherent explanation for why a project paper supposedly prepared for an ITOL application in 2002 would be converted to PDF by an employee of one of his companies in 2014. See: {CSW/2/59} to {CSW/2/60}. 120. In his oral evidence, Dr Wright tried to explain away the fact that (a) authentic versions of this document describe an IT security project (involving an encrypted network), with no reference to any digital transaction system and (b) this version (among others) includes the content of the authentic versions but adds incongruous sections referring to a peer-to-peer digital transaction system involving transactions being structured into “an ongoing chain of hash-based proof-of-work” to preclude double-spending or replay attacks. See {Day2/56:22} to {Day2/77:18}. Key aspects of his explanations and their deficiencies are addressed below. 121. This document is a forgery. Its content is not authentic to 2002, as Dr Wright claims it is. His attempts to explain away the indications of forgery should be rejected for the following reasons: 121.1. A version of this document in disclosure which Mr Madden has established as apparently authentic to 2002 ({ID000013}) is an internally coherent plan for an IT security system with three stages, in which the Stage 3 is described as the Final Phase and the budget covers three stages. It includes nothing about a digital transaction system, still less one involving a chain of hash-based proof-of-work. 121.2. Similarly, a project plan for this IT project which Dr Wright actually submitted to AusIndustry in 2003 has the same content as that apparently authentic document: {L1/113/1} [p8ff. Both the application form {L/113/3} and the project plan {L/113/8} were consistent in their description of the project. Neither says anything about a digital transaction system, still less one involving a chain of hash-based proof-of-work. 121.3. Even an apparently authentic version of the project plan in disclosure which dates to March 2009 {ID_001016} shows the project in the same terms, concluding with Stage 3 and including nothing about a digital currency system. 121.4. In this reliance document {ID_001379}, as in some other (similarly inauthentic) versions of the project plan in disclosure, Dr Wright has added an Abstract (at p4) which describes a digital transaction system similar to Bitcoin. The Abstract bears no obvious relation to the various other parts of the document, which are survivals of the authentic version, such as the Overall Objective section at p6 and the Assessment Against the Selection Criteria section at p8. Dr Wright has also added a few references to a Stage 4 involving the development of the supposed digital transaction system. However, he has forgotten to modify the budget on p11-12, which makes no financial provision for the supposed Stage 4 and still describes Stage 3 as the Final Phase. 121.5. In the Kleiman trial, Dr Wright said that parts of the Bitcoin White Paper went back to his “2002 AusIndustry filings for research and development”: see {L17/327/93}. When that evidence was put to him in this trial, he insisted that the document including the supposed Stage 4 elements of the project (involving a digital transaction system) “would have been filed [with AusIndustry] in 2002 and then in 2003”: {Day2/72:24}. That evidence was flatly contradicted by the actual AusIndustry filing from July 2003 (summarised above). 121.6. Dr Wright has attempted to account for these documents by a confused narrative of different versions of the document being in existence in 2002 and 2009 and used for different purposes, while the version control was in a state of chaos (see transcript reference above). The documents tell their own clear story: that Dr Wright produced an IT security project plan in 2002, which he used for tax concession applications, but he later (from 2014) doctored that plan to bolt on sections reflecting features of the Bitcoin system in order to promote his false claim to have been involved in creating that system. (d) Conclusion 122. I am entirely satisfied that the Project BlackNet paper was forged by Dr Wright. Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.

This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 7 of 42. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part of this filing here . This part is 7 of 42. HackerNoon’s Legal PDF Series HackerNoon’s Legal PDF Series here here 5. “Project BlackNet” paper (Reliance Document) {ID_001379} / {L1/79/1} 100. This document purports to be a copy of a “Project BlackNet” research paper dated on its face to 3 October 2002. The document contains references to a “Stage 4 – Release Phase” and other textual amendments, referring to “Digital Cash”, as well as other features of purported relevance to Bitcoin. 101. This document includes the text of the BlackNet Abstract (see the section above) pleaded as a forgery in COPA’s Particulars of Claim [26-27], and dealt with in the preceding section. (a) COPA’s Reasons for Alleging Forgery (a) COPA’s Reasons for Alleging Forgery 102. The document has been backdated [PM8 [60-61]. The document is dated on its face to 3 October 2002. However, the internal metadata for the document indicate that it was actually created on 17 February 2014. [PM8 [15]]. 103. The document is an edited version of an earlier document, into which passages of text have been inserted using text from the Bitcoin White Paper. [PM8 [23-33, 60.b.]]. 104. The document is apparently part of a series of documents, all of which carry similar content on their face, but which have been edited or are converted versions of the same file [PM8 [3]]. Some of those documents are consistent with a pattern of editing beginning with an earlier precursor document, and ending with a document which would be deployed as if it was original and authentic, in connection with Dr Wright’s claim to be Satoshi Nakamoto. See in particular Mr Madden’s discussion of {ID_001016} as another backdated document in the sequence [PM8 [34-50]]. 105. The metadata indicates that the file was created using Microsoft Word 2013 as the PDF Producer. Microsoft Word 2013 was not yet published in 2002 (the date on the face of the document) but is contemporaneous for 2014. [PM8 [15]]. 106. The document was created in PDF form by printing to PDF from an underlying precursor DOC or .DOCX document on 17 February 2014 [PM8 [16]]. No such underlying precursor document has been disclosed by Dr Wright. (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility 107. Dr Wright is listed in the metadata as the author of the document. 108. Dr Wright is listed on the face of the document as its first author. 109. Dr Wright is listed as the sole author in the ‘version control’ section of the document on page 2. 110. The document contains Dr Wright’s address and telephone number. 111. Dr Wright has positively asserted in these proceedings that this is a document on which he primarily relies as supporting his claim to be Satoshi Nakamoto. 112. The effect of the tampering is to make the document appear to be supportive of Dr Wright’s claim to be Satoshi Nakamoto (suggesting work done by him in 2002, elements of which then appeared in the Bitcoin White Paper), contrary to fact. 113. Dr Wright has posted screenshots of this document or a very similar document on Twitter, apparently in support of his claim to be Satoshi Nakamoto. 114. In his evidence in these proceedings, Dr Wright has claimed this to be a document related to the later Bitcoin White Paper and that it is original to the purported date on its face, contrary to fact. [Exhibit CSW 14]. 115. Dr Wright has relied on this document, or documents with similar content, in previous proceedings and in public in support of his claim to be Satoshi Nakamoto. 116. The metadata records “DeMorgan” as the company from which the document was created. In his evidence in these proceedings, Dr Wright relies on his work on various projects from his time at DeMorgan, as part of his claim to have been working on the concepts behind the Bitcoin White Paper. [Wright1 [32-47]]. 117. The document was created in the time zone UTC+11, consistent with Dr Wright’s location in Australia in February 2014, being the date of creation of the document. [PM8 [18]]. 118. In his Defence in these proceedings, in public social media posts, and elsewhere, Dr Wright has repeatedly stated that the series of research papers (to which this document belongs) are related to the Bitcoin White Paper, and that later applications (submitted in 2009/2010) contained the abstract of the Bitcoin White Paper. (c) Dr Wright’s Explanations and COPA’s Rebuttal (c) Dr Wright’s Explanations and COPA’s Rebuttal 119. In Appendix B to Wright11, Dr Wright accepted that this document was created by conversion of a document to PDF format in 2014. He claimed that this document was obtained from the computer of a former employee who had achieved unauthorised access to Dr Wright’s current wife’s email account, although he did not explain why that claim was relevant. He gave no coherent explanation for why a project paper supposedly prepared for an ITOL application in 2002 would be converted to PDF by an employee of one of his companies in 2014. See: {CSW/2/59} to {CSW/2/60}. 120. In his oral evidence, Dr Wright tried to explain away the fact that (a) authentic versions of this document describe an IT security project (involving an encrypted network), with no reference to any digital transaction system and (b) this version (among others) includes the content of the authentic versions but adds incongruous sections referring to a peer-to-peer digital transaction system involving transactions being structured into “an ongoing chain of hash-based proof-of-work” to preclude double-spending or replay attacks. See {Day2/56:22} to {Day2/77:18}. Key aspects of his explanations and their deficiencies are addressed below. 121. This document is a forgery. Its content is not authentic to 2002, as Dr Wright claims it is. His attempts to explain away the indications of forgery should be rejected for the following reasons: 121.1. A version of this document in disclosure which Mr Madden has established as apparently authentic to 2002 ({ID000013}) is an internally coherent plan for an IT security system with three stages, in which the Stage 3 is described as the Final Phase and the budget covers three stages. It includes nothing about a digital transaction system, still less one involving a chain of hash-based proof-of-work. 121.2. Similarly, a project plan for this IT project which Dr Wright actually submitted to AusIndustry in 2003 has the same content as that apparently authentic document: {L1/113/1} [p8ff. Both the application form {L/113/3} and the project plan {L/113/8} were consistent in their description of the project. Neither says anything about a digital transaction system, still less one involving a chain of hash-based proof-of-work. 121.3. Even an apparently authentic version of the project plan in disclosure which dates to March 2009 {ID_001016} shows the project in the same terms, concluding with Stage 3 and including nothing about a digital currency system. 121.4. In this reliance document {ID_001379}, as in some other (similarly inauthentic) versions of the project plan in disclosure, Dr Wright has added an Abstract (at p4) which describes a digital transaction system similar to Bitcoin. The Abstract bears no obvious relation to the various other parts of the document, which are survivals of the authentic version, such as the Overall Objective section at p6 and the Assessment Against the Selection Criteria section at p8. Dr Wright has also added a few references to a Stage 4 involving the development of the supposed digital transaction system. However, he has forgotten to modify the budget on p11-12, which makes no financial provision for the supposed Stage 4 and still describes Stage 3 as the Final Phase. 121.5. In the Kleiman trial, Dr Wright said that parts of the Bitcoin White Paper went back to his “2002 AusIndustry filings for research and development”: see {L17/327/93}. When that evidence was put to him in this trial, he insisted that the document including the supposed Stage 4 elements of the project (involving a digital transaction system) “would have been filed [with AusIndustry] in 2002 and then in 2003”: {Day2/72:24}. That evidence was flatly contradicted by the actual AusIndustry filing from July 2003 (summarised above). 121.6. Dr Wright has attempted to account for these documents by a confused narrative of different versions of the document being in existence in 2002 and 2009 and used for different purposes, while the version control was in a state of chaos (see transcript reference above). The documents tell their own clear story: that Dr Wright produced an IT security project plan in 2002, which he used for tax concession applications, but he later (from 2014) doctored that plan to bolt on sections reflecting features of the Bitcoin system in order to promote his false claim to have been involved in creating that system. (d) Conclusion (d) Conclusion 122. I am entirely satisfied that the Project BlackNet paper was forged by Dr Wright. Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. judiciary.uk judiciary.uk

So, About That BlackNet Paper... Looks Like It’s Not from 2002 After All

MAJURO, Marshall Islands, July 23rd, 2024/Chainwire/--Multipool, a leading innovator in the blockchain and cryptocurrency industry, today announces a strategic investment from Kronos Research. This investment solidifies Kronos’s stance of on-chain order books being the future of the industry and marks a significant milestone in strategic cooperation between the two companies and their commitment to decentralized finance. "We’re absolutely thrilled to be working with Kronos Research, with our expertise in the DeFi sector and the potential of our fully trustless decentralized on-chain orderbook, we envision an eventful future working with some of the best and brightest in the industry at Kronos Research." Steve Murray, Core Contributor at Multipool. "At Kronos, we have been leading the charge in liquidity provision, driven by our belief in trustless transactions and their transformative potential. We are thrilled to partner with Multipool to advance the digital asset landscape, providing enhanced solutions for global traders and investors." Vincent Liu, COO of Kronos Research The Future of Decentralized Finance Multipool’s aim of delivering a fully on-chain trustless orderbook to the DeFi industry aligns with Kronos’s vision of democratizing access to compliant advanced financial tools. This marks the first step in a long and fruitful partnership that will bring stability, awareness and access to a suite of full decentralized tools currently in high demand industry wide.  To learn more about Multipool and its features, users can visit: Website Telegram X CMC-Community About Multipool Multipool is a cutting-edge decentralized exchange (DEX) transforming the trading landscape for real-world assets (RWAs) and cryptocurrencies. Multipool is designed for fairness and equality, featuring a fully decentralized on-chain order book, deep liquidity through dynamic bracket pools, and seamless trading of RWAs and cryptocurrencies. Utilizing world-class innovations including industry-first FIX APIs, low latency networks, zero price impact auctions, trustless RFQs, peer-to-peer repo lending, and MEV bot protection, Multipool sets a new standard in DeFi trading. Experience unparalleled efficiency and security in the user's trading journey with Multipool – The DEX with CEX appeal. Website: https://www.multipool.finance/ About Kronos Research Kronos Research is a technology and data-driven trading firm transforming the digital asset landscape by cultivating a dynamic financial ecosystem with exceptional trading performance, advanced cryptocurrency investment strategies, and extensive liquidity provision capabilities. Their advanced machine-learning techniques and state-of-the-art trading infrastructure form the backbone of our quantitative trading operations. These enables them to deliver precise data and insights, bolster risk management, develop effective trading strategies, and empower informed investment decisions. By leveraging our expertise, they strive to foster strong partnerships and deliver significant value through continuous advancement and innovation. For further information or media inquiries, users can contact: Marketing Department marketing@kronosresearch.com Website: www.kronosresearch.com Social Media: [LinkedIn] [Twitter] [Facebook] [Instagram] Contact Public Relations Manager Angie Hermosa Multipool press@multipool.finance This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. MAJURO, Marshall Islands, July 23rd, 2024/Chainwire/--Multipool, a leading innovator in the blockchain and cryptocurrency industry, today announces a strategic investment from Kronos Research. This investment solidifies Kronos’s stance of on-chain order books being the future of the industry and marks a significant milestone in strategic cooperation between the two companies and their commitment to decentralized finance. "We’re absolutely thrilled to be working with Kronos Research, with our expertise in the DeFi sector and the potential of our fully trustless decentralized on-chain orderbook, we envision an eventful future working with some of the best and brightest in the industry at Kronos Research." Steve Murray, Core Contributor at Multipool. "We’re absolutely thrilled to be working with Kronos Research, with our expertise in the DeFi sector and the potential of our fully trustless decentralized on-chain orderbook, we envision an eventful future working with some of the best and brightest in the industry at Kronos Research." Steve Murray, Core Contributor at Multipool. "At Kronos, we have been leading the charge in liquidity provision, driven by our belief in trustless transactions and their transformative potential. We are thrilled to partner with Multipool to advance the digital asset landscape, providing enhanced solutions for global traders and investors." Vincent Liu, COO of Kronos Research "At Kronos, we have been leading the charge in liquidity provision, driven by our belief in trustless transactions and their transformative potential. We are thrilled to partner with Multipool to advance the digital asset landscape, providing enhanced solutions for global traders and investors." Vincent Liu, COO of Kronos Research The Future of Decentralized Finance Multipool’s aim of delivering a fully on-chain trustless orderbook to the DeFi industry aligns with Kronos’s vision of democratizing access to compliant advanced financial tools. This marks the first step in a long and fruitful partnership that will bring stability, awareness and access to a suite of full decentralized tools currently in high demand industry wide.  To learn more about Multipool and its features, users can visit: Website Website Telegram Telegram X X CMC-Community CMC-Community About Multipool Multipool is a cutting-edge decentralized exchange (DEX) transforming the trading landscape for real-world assets (RWAs) and cryptocurrencies. Multipool is designed for fairness and equality, featuring a fully decentralized on-chain order book, deep liquidity through dynamic bracket pools, and seamless trading of RWAs and cryptocurrencies. Multipool Multipool Utilizing world-class innovations including industry-first FIX APIs, low latency networks, zero price impact auctions, trustless RFQs, peer-to-peer repo lending, and MEV bot protection, Multipool sets a new standard in DeFi trading. Experience unparalleled efficiency and security in the user's trading journey with Multipool – The DEX with CEX appeal. Website: https://www.multipool.finance/ https://www.multipool.finance/ https://www.multipool.finance/ About Kronos Research Kronos Research is a technology and data-driven trading firm transforming the digital asset landscape by cultivating a dynamic financial ecosystem with exceptional trading performance, advanced cryptocurrency investment strategies, and extensive liquidity provision capabilities. Kronos Research Kronos Research Their advanced machine-learning techniques and state-of-the-art trading infrastructure form the backbone of our quantitative trading operations. These enables them to deliver precise data and insights, bolster risk management, develop effective trading strategies, and empower informed investment decisions. By leveraging our expertise, they strive to foster strong partnerships and deliver significant value through continuous advancement and innovation. For further information or media inquiries, users can contact: Marketing Department marketing@kronosresearch.com Website: www.kronosresearch.com www.kronosresearch.com www.kronosresearch.com Social Media: [LinkedIn] [Twitter] [Facebook] [Instagram] [LinkedIn] [LinkedIn] [Twitter] [Twitter] [Facebook] [Facebook] [Instagram] [Instagram] Contact Public Relations Manager Angie Hermosa Multipool press@multipool.finance This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

Multipool Secures Strategic Investment From Industry Giant Kronos Research

মাল্টিপুল ইন্ডাস্ট্রি জায়ান্ট ক্রোনোস রিসার্চ থেকে কৌশলগত বিনিয়োগ সুরক্ষিত করে

Multipool sichert sich strategische Investition vom Branchenriesen Kronos Research

Multipool obtiene una inversión estratégica del gigante de la industria Kronos Research

Multipool obtient un investissement stratégique du géant de l'industrie Kronos Research

मल्टीपूल को उद्योग की दिग्गज कंपनी क्रोनोस रिसर्च से रणनीतिक निवेश मिला

マルチプール、業界大手クロノス・リサーチから戦略的投資を獲得

Multipool, 거대 업계 Kronos Research로부터 전략적 투자 확보

Multipool garante investimento estratégico da gigante da indústria Kronos Research

Multipool обеспечивает стратегические инвестиции промышленного гиганта Kronos Research

Multipool, Endüstri Devi Kronos Research'ten Stratejik Yatırım Sağlıyor

Multipool đảm bảo đầu tư chiến lược từ công ty nghiên cứu Kronos khổng lồ trong ngành

Multipool 获得行业巨头 Kronos Research 的战略投资

Building a Blockchain From Scratch (kind of) with Polkadot SDK and Pop!

UMG Recordings, Inc. v. Verizon Communications Inc., Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. YYou can jump to any part of this filing here. This part is 10 of 11. PRAYER FOR RELIEF WHEREFORE, Plaintiffs pray for judgment from this Court against Verizon as follows: a. For a declaration that Verizon willfully infringed Plaintiffs’ copyrights; b. For statutory damages pursuant to 17 U.S.C. § 504(c), in an amount up to the maximum provided by law, arising from Verizon’s willful violations of Plaintiffs’ rights under the U.S. Copyright Act or, in the alternative, at Plaintiffs’ election, Plaintiffs’ actual damages pursuant to 17 U.S.C. § 504(b), including Verizon’s profits from infringement, in an amount to be proven at trial; c. For an award of Plaintiffs’ costs in this action, including reasonable attorneys’ fees, pursuant to 17 U.S.C. § 505; d. For pre-judgment and post-judgment interest at the applicable rate on any monetary award made part of the judgment against Verizon; and e. For such other and further relief as the Court deems proper. Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.
This court case retrieved on July 12, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. UMG Recordings, Inc. v. Verizon Communications Inc., Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. YYou can jump to any part of this filing here. This part is 10 of 11. UMG Recordings, Inc. v. Verizon Communications Inc., Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series . YYou can jump to any part of this filing here . This part is 10 of 11. HackerNoon’s Legal PDF Series HackerNoon’s Legal PDF Series here here PRAYER FOR RELIEF WHEREFORE, Plaintiffs pray for judgment from this Court against Verizon as follows: a. For a declaration that Verizon willfully infringed Plaintiffs’ copyrights; b. For statutory damages pursuant to 17 U.S.C. § 504(c), in an amount up to the maximum provided by law, arising from Verizon’s willful violations of Plaintiffs’ rights under the U.S. Copyright Act or, in the alternative, at Plaintiffs’ election, Plaintiffs’ actual damages pursuant to 17 U.S.C. § 504(b), including Verizon’s profits from infringement, in an amount to be proven at trial; c. For an award of Plaintiffs’ costs in this action, including reasonable attorneys’ fees, pursuant to 17 U.S.C. § 505; d. For pre-judgment and post-judgment interest at the applicable rate on any monetary award made part of the judgment against Verizon; and e. For such other and further relief as the Court deems proper. Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on July 12, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on July 12, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. storage.courtlistener

Music Industry Demands Statutory Damages from Verizon in Copyright Lawsuit

From Business Mindset to Creativity

ব্যবসায়িক মানসিকতা থেকে সৃজনশীলতা পর্যন্ত

Vom Business Mindset zur Kreativität

De la mentalidad empresarial a la creatividad

De l’esprit d’entreprise à la créativité

व्यावसायिक मानसिकता से रचनात्मकता तक

ビジネスマインドセットから創造性へ

비즈니스 마인드에서 창의성까지

Da mentalidade empresarial à criatividade

От делового мышления к творчеству

İş Zihniyetinden Yaratıcılığa

Từ tư duy kinh doanh đến sáng tạo

从商业思维到创造力

I have 9 years of experience as a venture investor, and I can confirm that one of the most important things in a startup’s early stages is the team. Therefore, whether or not I decide to invest in a project largely depends on my meeting with its founder. In addition to convincing me with figures, he/she needs to build trust. While I might feel ready to invest after the first meeting, I often take some weeks to reflect. These are the qualities that influenced my decision. Industry Knowledge and Experience As a founder, you must know the ins and outs of any industry you want to venture into. For example, a fintech entrepreneur with prior experience in the banking sector will offer invaluable expertise. This is a quality I appraise, as it means you have a firsthand understanding of the industry's pain points and nuances. As an investor, I also consider the educational background of the founder. I inquire about their academic achievements, including grades and thesis topics. A solid educational foundation adds credibility to the founder's qualifications. Entrepreneurial Background Entrepreneurship is a rare talent; from my experience, only about 2% of individuals inherently possess it. In most cases, experience is the best teacher. Therefore, I value founders who have gained experience in large corporations before embarking on their own ventures. Additionally, I have greater confidence in founders who have undergone 1-2 unsuccessful projects. In my view, success alone doesn't provide valuable lessons; it's the mistakes and setbacks that offer profound learning opportunities. It's crucial that a founder evaluates these experiences and learns from them. Willingness to Admit Mistakes and Accept Change Periodically, I meet founders who don’t take criticism well. They find it difficult to admit mistakes and often accept a single hypothesis as the truth. But to make an idea work, you need to test 5-10 hypotheses, adapt the model, and possibly make a pivot. Instead, they're stuck on one idea and keep forcing it; even if it's not improving. Beyond the product itself, there are external factors necessary for growth. Hiring the right team, building a marketing strategy, finding enablers, and so on. Experienced investors with foresight can discover potential pitfalls and highlight blind spots, but not every founder is an open listener. As much as I value entrepreneurial experience and industry expertise, founders need to remain flexible so that their experience helps, and not hinders, the startup's growth. Honesty I value honesty right from early communication with the founder. My confidence in a project grows when founders openly discuss challenges, setbacks, and whatever isn’t working. Sometimes, initial hypotheses don't pan out, but determined founders continue to explore and iterate. Other times, customer acquisition costs may be prohibitively high, prompting them to experiment with new acquisition or investment channels. Being candid about what's not working demonstrates integrity, resilience, and a commitment to finding solutions. On the other hand, if founders withhold information about their challenges, it diminishes my confidence in the project. As long as I believe in the vision, I’m always open to offering solutions where possible. Passion Building a startup often spans a decade-long journey. Passion is needed to drive the commitment to see this long path through. Therefore, I look at how passionate a founder is about his/her project, and how deeply immersed they are in the topic. I also prioritize understanding a founder's commitment level and endgame aspirations — whether they are ready to dedicate themselves fully to the project, aiming for a profitable exit, or seeking to establish a lasting legacy for future generations. For instance, one founder candidly expressed a desire to exit the startup within 3-5 years. In response, I adjusted my expectations accordingly and focused on realistic growth targets rather than aiming for astronomical returns. Conclusion Successful tech entrepreneurs have a fine blend of unique skills, industry expertise, and unwavering passion. In my view, to achieve success, a founder must be 120% committed to their startup, whether it’s for the short or long term. They must also be adaptable and not overlook potential challenges. A final word to the upcoming innovators and industry disruptors: When engaging with investors, demonstrate your expertise and unwavering motivation. To build trust, be transparent in your dealings and forthright about the obstacles you face. Substantiate your claims with solid data to crown your efforts. Adopting this approach will significantly enhance your prospects of securing funding. I have 9 years of experience as a venture investor, and I can confirm that one of the most important things in a startup’s early stages is the team. Therefore, whether or not I decide to invest in a project largely depends on my meeting with its founder. In addition to convincing me with figures, he/she needs to build trust. While I might feel ready to invest after the first meeting, I often take some weeks to reflect. These are the qualities that influenced my decision. Industry Knowledge and Experience Industry Knowledge and Experience As a founder, you must know the ins and outs of any industry you want to venture into. For example, a fintech entrepreneur with prior experience in the banking sector will offer invaluable expertise. This is a quality I appraise, as it means you have a firsthand understanding of the industry's pain points and nuances. As an investor, I also consider the educational background of the founder. I inquire about their academic achievements, including grades and thesis topics. A solid educational foundation adds credibility to the founder's qualifications. Entrepreneurial Background Entrepreneurial Background Entrepreneurship is a rare talent; from my experience, only about 2% of individuals inherently possess it. In most cases, experience is the best teacher. Therefore, I value founders who have gained experience in large corporations before embarking on their own ventures. Additionally, I have greater confidence in founders who have undergone 1-2 unsuccessful projects. In my view, success alone doesn't provide valuable lessons; it's the mistakes and setbacks that offer profound learning opportunities. It's crucial that a founder evaluates these experiences and learns from them. Willingness to Admit Mistakes and Accept Change Willingness to Admit Mistakes and Accept Change Periodically, I meet founders who don’t take criticism well. They find it difficult to admit mistakes and often accept a single hypothesis as the truth. But to make an idea work, you need to test 5-10 hypotheses, adapt the model, and possibly make a pivot. Instead, they're stuck on one idea and keep forcing it; even if it's not improving. Beyond the product itself, there are external factors necessary for growth. Hiring the right team, building a marketing strategy, finding enablers, and so on. Experienced investors with foresight can discover potential pitfalls and highlight blind spots, but not every founder is an open listener. As much as I value entrepreneurial experience and industry expertise, founders need to remain flexible so that their experience helps, and not hinders, the startup's growth. Honesty Honesty I value honesty right from early communication with the founder. My confidence in a project grows when founders openly discuss challenges, setbacks, and whatever isn’t working. Sometimes, initial hypotheses don't pan out, but determined founders continue to explore and iterate. Other times, customer acquisition costs may be prohibitively high, prompting them to experiment with new acquisition or investment channels. Being candid about what's not working demonstrates integrity, resilience, and a commitment to finding solutions. On the other hand, if founders withhold information about their challenges, it diminishes my confidence in the project. As long as I believe in the vision, I’m always open to offering solutions where possible. Passion Passion Building a startup often spans a decade-long journey. Passion is needed to drive the commitment to see this long path through. Therefore, I look at how passionate a founder is about his/her project, and how deeply immersed they are in the topic. I also prioritize understanding a founder's commitment level and endgame aspirations — whether they are ready to dedicate themselves fully to the project, aiming for a profitable exit, or seeking to establish a lasting legacy for future generations. For instance, one founder candidly expressed a desire to exit the startup within 3-5 years. In response, I adjusted my expectations accordingly and focused on realistic growth targets rather than aiming for astronomical returns. Conclusion Conclusion Successful tech entrepreneurs have a fine blend of unique skills, industry expertise, and unwavering passion. In my view, to achieve success, a founder must be 120% committed to their startup, whether it’s for the short or long term. They must also be adaptable and not overlook potential challenges. A final word to the upcoming innovators and industry disruptors: A final word to the upcoming innovators and industry disruptors: When engaging with investors, demonstrate your expertise and unwavering motivation. To build trust, be transparent in your dealings and forthright about the obstacles you face. Substantiate your claims with solid data to crown your efforts. Adopting this approach will significantly enhance your prospects of securing funding.

Which Founders Do Investors Trust? Insights From a Business Angel Who Invested in 52 Startups

Stories, News & Mentions about FRDM

Frdm’s Stories on HackerNoon