## Inspiration

Let's face it: Museums, parks, and exhibits need some work in this digital era. Why lean over to read a small plaque when you can get a summary and details by tagging exhibits with a portable device?
There is a solution for this of course: NFC tags are a fun modern technology, and they could be used to help people appreciate both modern and historic masterpieces. Also there's one on your chest right now!

## The Plan

Whenever a tour group, such as a student body, visits a museum, they can streamline their activities with our technology. When a member visits an exhibit, they can scan an NFC tag to get detailed information and receive a virtual collectible based on the artifact. The goal is to facilitate interaction amongst the museum patrons for collective appreciation of the culture. At any time, the members (or, as an option, group leaders only) will have access to a live slack feed of the interactions, keeping track of each other's whereabouts and learning.

## How it Works

When a user tags an exhibit with their device, the Android mobile app (built in Java) will send a request to the StdLib service (built in Node.js) that registers the action in our MongoDB database, and adds a public notification to the real-time feed on slack.

## The Hurdles and the Outcome

Our entire team was green to every technology we used, but our extensive experience and relentless dedication let us persevere. Along the way, we gained experience with deployment oriented web service development, and will put it towards our numerous future projects. Due to our work, we believe this technology could be a substantial improvement to the museum industry.

## Extensions

Our product can be easily tailored for ecotourism, business conferences, and even larger scale explorations (such as cities and campus). In addition, we are building extensions for geotags, collectibles, and information trading.
## Inspiration

We are very interested in the intersection of the financial sector and engineering, and wanted to find a way to speed up computation time in relation to option pricing through simulations.

## What it does

Bellcrve is a distributed computing network that simulates monte carlo methods on financial instruments to perform option pricing. Using Wolfram as its power source, we are able to converge very fast. The idea was it showcase how much faster these computations become when we distribute across a network of 10 mchines, with up to 10,000 simulations running.

## How we built it

We spun up 10 Virtual Machines on DigitalOcean, setup 8 as the worker nodes, 1 node for the Master, and 1 for the Scheduler to distribute the simulations across the nodes as they became free. We implemented our model using a monte carlo simulation that takes advantage of the Geometric Brownian Motion and Black Scholes Model. GBM is responsible for modeling the assets price path over the course of the simulation. We start the simulation at the stocks current price and observe how it changes as the number of steps increases. The Black Scholes Model is responsible for pricing the stocks theoretical price based on the volatility and time decay. We observed how our simulation converges between the GBM and Black Scholes model as the number of steps and iterations increases, effectively giving us a low error rate.

We developed it using Wolfram, Python, Flask, Dask, React, and Next.JS, D3.JS. Wolfram and Python are responsible for most of the Monte Carlo simulations as well as the backend API and websocket. We used Dask to help manage our distributed network connecting us to our VM's in Digital Ocean. And we used React, and Next.JS to build out the web app and visualized all charts in real-time with D3.JS. Wolfram was crucial to our application being able to converge faster proving that distributing the simulations will help save resources, and speed up simulation times. We packaged up the math behind the Monte Carlo simulation and deployed it as Pypi for others to use.

## Challenges we ran into

We had many challenges along the way, across all fronts. First, we had issues with the websocket trying to connect to our client side, and found out it was due to WSS issues. We then ran into some CORS errors that we were able to sort out. Our formulas kept evolving as we made progress on our application, and we had to account for this change. We realized we needed a different metric from the model and needed to shift in that direction. Setting up the cluster of machines was challenging and took some time to dig into.

## Accomplishments that we're proud of

We are proud to say we pushed a completed application, and deployed it to Vercel. Our application allows users to simulate different stocks and price their options in real time and observe how it converges for different number of simulations.

## What we learned

We learned a lot about websockets, creating real-time visualizations, and having our project depend on the math. This was our first time using Wolfram for our project, and we really enjoyed working with it. We have used similar languages like matlab and python, but we found Wolfram to help us speed up our computations signficantly.

## What's next for Lambda Labs

We hope to continue to improve our application, and bring this to different areas in the financial sector, not just options pricing.
## Inspiration

With the number of candidates rising in the industry in comparison to the job positions, conducting interviews and deciding on candidates carefully has become a critical task. Along with this ratio imbalance, there are an increasing number of candidates that are forging their experience to gain an unfair advantage over others.

## What it does

The project provides AI interview solution which conducts a human-like interview and deploy AI agents in the backend to verify the authenticity of the candidate.

## How we built it

The project was building NextJS as frontend, and NodeJS as backend. The AI service was provided by Hume, along with Single Store as the backend database. We also used Fetch AI to deploy the AI agents that verify the authenticity.

## Challenges we ran into

Some challenges we ran into were related to integrating Hume into our frontend. Managing the conversation data and inferring it to provide feedback was also tricky.

## Accomplishments that we're proud of

Being able to build a working MVP within 2 days of hacking. Integrating hume AI and being able to persist and maintain conversation transcripts that was later used to make inference.

## What we learned

We learned about using and integrating AI agents to help us with important tasks. Having used Hume AI also provided us with insights on different emotions captured by the AI service that can be used in a lot of downstream tasks.

## What's next for Candidate Compare

We plan on expanding the scope of our candidate information verification to include more thorough checks. We also plan to partner with a couple of early stage adopters to use Candidate Compare and benefit from reduced hiring loads.