Vector-Field Consistency is a consistency model for replicated data (for example, objects), initially described in a paper which was awarded the best-paper prize in the ACM/IFIP/Usenix Middleware Conference 2007. It has since been enhanced for increased scalability and fault-tolerance in a recent paper. == Description == This consistency model was initially designed for replicated data management in ad hoc gaming in order to minimize bandwidth usage without sacrificing playability. Intuitively, it captures the notion that although players require, wish, and take advantage of information regarding the whole of the game world (as opposed to a restricted view to rooms, arenas, etc. of limited size employed in many multiplayer video games), they need to know information with greater freshness, frequency, and accuracy as other game entities are located closer and closer to the player's position. It prescribes a multidimensional divergence bounding scheme, based on a vector field that employs consistency vectors k=(θ,σ,ν), standing for maximum allowed time - or replica staleness, sequence - or missing updates, and value - or user-defined measured replica divergence, applied to all space coordinates in game scenario or world. The consistency vector-fields emanate from field-generators designated as pivots (for example, players) and field intensity attenuates as distance grows from these pivots in concentric or square-like regions. This consistency model unifies locality-awareness techniques employed in message routing and consistency enforcement for multiplayer games, with divergence bounding techniques traditionally employed in replicated database and web scenarios.
Observability (software)
In software engineering, more specifically in distributed computing, observability is the ability to collect data about programs' execution, modules' internal states, and the communication among components. To improve observability, software engineers use a wide range of logging and tracing techniques to gather telemetry information, and tools to analyze and use it. Observability is foundational to site reliability engineering, as it is the first step in triaging a service outage. One of the goals of observability is to minimize the amount of prior knowledge needed to debug an issue. == Etymology, terminology and definition == The term is borrowed from control theory, where the "observability" of a system measures how well its state can be determined from its outputs. Similarly, software observability measures how well a system's state can be understood from the obtained telemetry (metrics, logs, traces, profiling). The definition of observability varies by vendor: Observability is the process of making a system’s internal state more transparent. Systems are made observable by the data they produce, which in turn helps you to determine if your infrastructure or application is healthy and functioning normally. a measure of how well you can understand and explain any state your system can get into, no matter how novel or bizarre [...] without needing to ship new code software tools and practices for aggregating, correlating and analyzing a steady stream of performance data from a distributed application along with the hardware and network it runs onobservability starts by shipping all your raw data to central service before you begin analysisthe ability to measure a system’s current state based on the data it generates, such as logs, metrics, and traces Observability is tooling or a technical solution that allows teams to actively debug their system. Observability is based on exploring properties and patterns not defined in advance. proactively collecting, visualizing, and applying intelligence to all of your metrics, events, logs, and traces—so you can understand the behavior of your complex digital system The term is frequently referred to as its numeronym o11y (where 11 stands for the number of letters between the first letter and the last letter of the word). This is similar to other computer science abbreviations such as i18n and l10n and k8s. === Observability vs. monitoring === Observability and monitoring are sometimes used interchangeably. As tooling, commercial offerings and practices evolved in complexity, "monitoring" was re-branded as observability in order to differentiate new tools from the old. The terms are commonly contrasted in that systems are monitored using predefined sets of telemetry, and monitored systems may be observable. Majors et al. suggest that engineering teams that only have monitoring tools end up relying on expert foreknowledge (seniority), whereas teams that have observability tools rely on exploratory analysis (curiosity). == Telemetry types == Observability relies on three main types of telemetry data: metrics, logs and traces. Those are often referred to as "pillars of observability". === Metrics === A metric is a point in time measurement (scalar) that represents some system state. Examples of common metrics include: number of HTTP requests per second; total number of query failures; database size in bytes; time in seconds since last garbage collection. Monitoring tools are typically configured to emit alerts when certain metric values exceed set thresholds. Thresholds are set based on knowledge about normal operating conditions and experience. Metrics are typically tagged to facilitate grouping and searchability. Application developers choose what kind of metrics to instrument their software with, before it is released. As a result, when a previously unknown issue is encountered, it is impossible to add new metrics without shipping new code. Furthermore, their cardinality can quickly make the storage size of telemetry data prohibitively expensive. Since metrics are cardinality-limited, they are often used to represent aggregate values (for example: average page load time, or 5-second average of the request rate). Without external context, it is impossible to correlate between events (such as user requests) and distinct metric values. === Logs === Logs, or log lines, are generally free-form, unstructured text blobs that are intended to be human readable. Modern logging is structured to enable machine parsability. As with metrics, an application developer must instrument the application upfront and ship new code if different logging information is required. Logs typically include a timestamp and severity level. An event (such as a user request) may be fragmented across multiple log lines and interweave with logs from concurrent events. === Traces === ==== Distributed traces ==== A cloud native application is typically made up of distributed services which together fulfill a single request. A distributed trace is an interrelated series of discrete events (also called spans) that track the progression of a single user request. A trace shows the causal and temporal relationships between the services that interoperate to fulfill a request. Instrumenting an application with traces means sending span information to a tracing backend. The tracing backend correlates the received spans to generate presentable traces. To be able to follow a request as it traverses multiple services, spans are labeled with unique identifiers that enable constructing a parent-child relationship between spans. Span information is typically shared in the HTTP headers of outbound requests. === Continuous profiling === Continuous profiling is another telemetry type used to precisely determine how an application consumes resources. === Instrumentation === To be able to observe an application, telemetry about the application's behavior needs to be collected or exported. Instrumentation means generating telemetry alongside the normal operation of the application. Telemetry is then collected by an independent backend for later analysis. In fast-changing systems, instrumentation itself is often the best possible documentation, since it combines intention (what are the dimensions that an engineer named and decided to collect?) with the real-time, up-to-date information of live status in production. Instrumentation can be automatic, or custom. Automatic instrumentation offers blanket coverage and immediate value; custom instrumentation brings higher value but requires more intimate involvement with the instrumented application. Instrumentation can be native - done in-code (modifying the code of the instrumented application) - or out-of-code (e.g. sidecar, eBPF). Verifying new features in production by shipping them together with custom instrumentation is a practice called "observability-driven development". == "Pillars of observability" == Metrics, logs and traces are most commonly listed as the pillars of observability. Majors et al. suggest that the pillars of observability are high cardinality, high-dimensionality, and explorability, arguing that runbooks and dashboards have little value because "modern systems rarely fail in precisely the same way twice." == Self monitoring == Self monitoring is a practice where observability stacks monitor each other, in order to reduce the risk of inconspicuous outages. Self monitoring may be put in place in addition to high availability and redundancy to further avoid correlated failures.
Inbenta
Inbenta is an AI company that originated in Barcelona, Spain, in 2005. Inbenta is currently headquartered in Allen, Texas, with additional offices in Spain, São Paulo, Brazil, Toulouse, France, and Tokyo, Japan. Inbenta provides natural language processing and semantic search through artificial intelligence. == History == Inbenta raised $12 Million in their Series B funding round to extend the reach of their artificial intelligence for business solutions. In 2023 Inbenta's new chief executive officer Melissa Solis moved Inbenta's headquarters to One Bethany West in Allen, Texas from Foster City, California. == Controversy == On 23 June 2018, Ticketmaster UK identified malicious software on a customer support product hosted by Inbenta Technologies, compromising personal data and payment details for thousands of Ticketmaster customers. Three days later, Inbenta's CEO Issued a message about the incident to convey the full scope of the breach. Also on its FAQ section, Inbenta claimed that "After a careful analysis of all clues and snapshots from our systems, the technical team at Inbenta discovered that the script had been implemented on the payment page. We were unaware of this, and would have advised against doing so had we known, as it presents a point of vulnerability". On November 13, 2020, the Information Commissioner's Office fined Ticketmaster UK Limited £1.25 million for failing to protect customers' payment details. According to the ICO, "It was because of Ticketmaster's business decision to include the [Inbenta] chat bot on its payment page that the chat bot was able to unlawfully process the personal data of customers."
Agent Communications Language
Agent Communication Language (ACL) consists of computer communication protocols that are intended for AI agents to communicate with each other. In 2007, protocols of this nature were proposed which include: FIPA-ACL (by the Foundation for Intelligent Physical Agents, a standardization consortium) KQML (Knowledge Query and Manipulation Language) After the surge in Generative AI with the use of Transformers and Large language models, the definition of agent has shifted away from physical agents to signify software systems built using the principles of Agentic AI. A new protocol to emerge in this area is Natural Language Interaction Protocol (NLIP). NLIP is an application-level communication protocol defined between AI Agents or between a human and an AI agent. Ecma International; a standards body which develops and publishes international standards for the information and communication industry; published on 10 December 2025 five new standards and one technical report defining the Natural Language Interaction Protocol (NLIP). As a result, we can define agent communication protocols into two categories: ontology based agent communication protocols and generative AI based agent communication protocols. Ontology based agent communication protocols use a common ontology to be used between agents. An ontology is a part of the agent's knowledge base that describes what kind of things an agent can deal with and how they are related to each other. FIPA-ACL and KQML are examples of such protocols. These protocols rely on speech act theory developed by Searle in the 1960s and enhanced by Winograd and Flores in the 1970s. They define a set of performatives, also called Communicative Acts, and their meaning (e.g. ask-one). The content of the performative is not standardized, but varies from system to system. Implementation support of FIPA-ACL is included in FIPA-OS and Jade. Generative AI based agent communication protocols such as NLIP do not require a shared ontology among communicating agents. In its stead, they use generative AI models to translate natural language text, images, videos or other modalities of data into a local ontology. This provides for hot-extensibility where the same protocol can be used for multiple communication needs, and simplifies version control since different agents can use different versions of a shared ontology. NLIP has been designed with security considerations in mind. The specification and standards comprising NLIP are developed and maintained by Ecma Technical Community 56.
Computer Science Ontology
The Computer Science Ontology (CSO) is an automatically generated taxonomy of research topics in the field of Computer Science. It was produced by the Open University in collaboration with Springer Nature by running an information extraction system over a large corpus of scientific articles. Several branches were manually improved by domain experts. The current version (CSO 3.2) includes about 14K research topics and 160K semantic relationships. CSO is available in OWL, Turtle, and N-Triples. It is aligned with several other knowledge graphs, including DBpedia, Wikidata, YAGO, Freebase, and Cyc. New versions of CSO are regularly released on the CSO Portal. CSO is mostly used to characterise scientific papers and other documents according to their research areas, in order to enable different kinds of analytics. The CSO Classifier is an open-source python tool for automatically annotating documents with CSO. == Applications == Recommender Systems. Computing the semantic similarity of documents. Extracting metadata from video lecture subtitles. Performing bibliometrics analysis.
Conversica
Conversica is a US-based cloud software technology company, headquartered in San Mateo, California, that provides two-way AI-driven conversational software and a suite of Intelligent Virtual Assistants for businesses to engage customers via email, chat, and SMS. == History == 2007: The company was founded by Ben Brigham in Bellingham, Washington, originally as AutoFerret.com. The company's initial product was a Customer Relationship Management (CRM) targeted at automotive dealerships. This soon expanded to lead generation, and then lead validation and qualification. The AI Conversica uses currently was made to follow up on and filter out low-quality leads. The focus of the company shifted toward this automated lead engagement technology. 2010: The company started commercially selling AVA, the first Automated Virtual Assistant for sales, and the company name was changed to AVA.ai. Early customers for AVA were automotive dealerships. As the company moved away from generating leads themselves, and providing the CRM themselves, it became necessary to integrate with existing CRM and Marketing Automation platforms, such as DealerSocket, VinSolutions and Salesforce. 2013: The company raised $16m Series A funding, led by Kennet Partners, and named Mark Bradley as CEO. It also moved its headquarters from Bellingham, Washington to Foster City, California. 2014: The company changed its name from AVA.ai to Conversica. 2015: Alex Terry joined Conversica as its CEO. The business expanded to include customers in additional verticals, including technology, education, and financial services. 2016: The company raised $34m Series B funding, led by Providence Strategic Growth. 2017: Conversica expanded its intelligent automation platform and IVAs to support additional communication channels (e-mail and SMS text messaging) and communication languages. Conversica also opened a new technology center in Seattle, Washington to expand its AI and machine learning capabilities. 2018: The company raised $31m Series C funding, led by Providence Strategic Growth. Conversica also acquired Intelligens.ai, providing a regional presence in Latin America with an office in Las Condes, Santiago, Chile. The company launched an AI-powered Admissions Assistant for Higher Education industry. 2019: Conversica was selected by Fast Company magazine as one of the Top 10 Most Innovative AI Companies in the World, and was named Marketo's Technology Partner of the Year. The company officially expanded into the EMEA region with the opening of a London office. As of August 2019, Conversica has over 50 different integrations with third parties. In October Conversica won three awards at the fourth annual Global Annual Achievement Awards for Artificial Intelligence. Also that month, Alex Terry stepped down from his role as CEO and was replaced by Jim Kaskade. 2020: As part of Conversica's response to COVID-19, they optimized the business to become profitable in both 2Q20 and 3Q20, before reinvesting in 4Q20. The company transitioned both international operations in EMEA and LATAM to an indirect model with partners (LeadFabric and Nectia Cloud Solutions respectively), and moved a portion of its US-based employees to near-shore centers in Mexico and Brazil, effectively downsizing the company from 250 to 200. Conversica's reseller partner, Nectia, is a major Latin American affiliate and Chile's number one Salesforce partner, and, as part of the partnership, Nectia devoted capital to a brand new company segment, Predict-IA, dedicated to web-based artificial intelligent solutions. Predict-IA was able to immediately service all LATAM opportunities and clients with Conversica's AI Assistants with end-to-end services (marketing, sales, professional services, customer success, and technical support). Conversica's reseller partner, Leadfabric, has offices in Belgium, Amsterdam, Paris, UK, Taiwan, and Romania. == Technology == Conversica's Revenue Digital Assistants™ are AI assistants who engage with leads, prospects, customers, employees, and other persons of interest (Contacts) in a two-way human-like manner, via email, SMS text, and website chat, in English, French, German, Spanish, Portuguese, and Japanese. The RDAs are built on an Intelligent Automation platform that leverages natural language understanding, natural language processing, natural language generation, deep learning and machine learning. The Assistants are generally deployed alongside sales and marketing, customer success, account management, and higher education admissions teams, as part of an augmented workforce. The Intelligent Automation platform integrates with over 50 external systems, including CRM, Marketing Automation, and other systems of record. A partial list of integration partners includes: Salesforce, Marketo, Oracle, HubSpot, DealerSocket, Reynolds & Reynolds, CDK Global, VinSolutions and many more.
Resilience (mathematics)
In mathematical modeling, resilience refers to the ability of a dynamical system to recover from perturbations and return to its original stable steady state. It is a measure of the stability and robustness of a system in the face of changes or disturbances. If a system is not resilient enough, it is more susceptible to perturbations and can more easily undergo a critical transition. A common analogy used to explain the concept of resilience of an equilibrium is one of a ball in a valley. A resilient steady state corresponds to a ball in a deep valley, so any push or perturbation will very quickly lead the ball to return to the resting point where it started. On the other hand, a less resilient steady state corresponds to a ball in a shallow valley, so the ball will take a much longer time to return to the equilibrium after a perturbation. The concept of resilience is particularly useful in systems that exhibit tipping points, whose study has a long history that can be traced back to catastrophe theory. While this theory was initially overhyped and fell out of favor, its mathematical foundation remains strong and is now recognized as relevant to many different systems. == History == In 1973, Canadian ecologist C. S. Holling proposed a definition of resilience in the context of ecological systems. According to Holling, resilience is "a measure of the persistence of systems and of their ability to absorb change and disturbance and still maintain the same relationships between populations or state variables". Holling distinguished two types of resilience: engineering resilience and ecological resilience. Engineering resilience refers to the ability of a system to return to its original state after a disturbance, such as a bridge that can be repaired after an earthquake. Ecological resilience, on the other hand, refers to the ability of a system to maintain its identity and function despite a disturbance, such as a forest that can regenerate after a wildfire while maintaining its biodiversity and ecosystem services. With time, the once well-defined and unambiguous concept of resilience has experienced a gradual erosion of its clarity, becoming more vague and closer to an umbrella term than a specific concrete measure. == Definition == Mathematically, resilience can be approximated by the inverse of the return time to an equilibrium given by resilience ≡ − Re ( λ 1 ( A ) ) {\displaystyle {\text{resilience}}\equiv -{\text{Re}}(\lambda _{1}({\textbf {A}}))} where λ 1 {\textstyle \lambda _{1}} is the maximum eigenvalue of matrix A {\textstyle {\textbf {A}}} . The largest this value is, the faster a system returns to the original stable steady state, or in other words, the faster the perturbations decay. == Applications and examples == In ecology, resilience might refer to the ability of the ecosystem to recover from disturbances such as fires, droughts, or the introduction of invasive species. A resilient ecosystem would be one that is able to adapt to these changes and continue functioning, while a less resilient ecosystem might experience irreversible damage or collapse. The exact definition of resilience has remained vague for practical matters, which has led to a slow and proper application of its insights for management of ecosystems. In epidemiology, resilience may refer to the ability of a healthy community to recover from the introduction of infected individuals. That is, a resilient system is more likely to remain at the disease-free equilibrium after the invasion of a new infection. Some stable systems exhibit critical slowing down where, as they approach a basic reproduction number of 1, their resilience decreases, hence taking a longer time to return to the disease-free steady state. Resilience is an important concept in the study of complex systems, where there are many interacting components that can affect each other in unpredictable ways. Mathematical models can be used to explore the resilience of such systems and to identify strategies for improving their resilience in the face of environmental or other changes. For example, when modelling networks it is often important to be able to quantify network resilience, or network robustness, to the loss of nodes. Scale-free networks are particularly resilient since most of their nodes have few links. This means that if some nodes are randomly removed, it is more likely that the nodes with fewer connections are taken out, thus preserving the key properties of the network.