AI Enterprise SolutionsGPT & Claude

Hososhi

The User Hososhi is for the people who are responsible for getting work done inside a company — operations managers, process owners, department managers, and automation teams. They know what the official process is supposed to look like. The problem is that the real process is often different. The Problem A company might say: “This is how we process a purchase request.” But in reality, an employee might check an old email, ask a colleague on Slack, look through a previous decision, make an extra verification, and then send it to a manager. Those small steps are usually not written down anywhere. Over time, they become part of how the company actually works. This creates a simple but important problem: Before you can automate a workflow, you need to know what the workflow really is. Companies often spend time documenting processes or automating the process they think they have, without seeing all the hidden steps and reasons behind them. That can lead to automating the wrong thing, removing an important control, or missing opportunities to automate repetitive work. Hososhi starts from the other direction. Instead of asking the company to describe its workflow first, it looks at the activity happening around the work and discovers the workflow from it. Then it helps people understand why each step exists, what evidence supports it, and which parts can safely be automated. In short: Companies automate the workflows they think they have. Hososhi discovers the workflows they actually have.

Open the demo GitHub

Preliminary score

37.0/ 100Earlyaverage of 2 judges

Value for the user15.5 / 25
A specific problem and a clear outcome from solving it.
Prototype and use of AI9.5 / 30
A working core scenario, and what AI actually contributes to the result.
Quality testing2.5 / 20
Tests, examples of failures, and comparison with the current approach.
Feasibility4.5 / 15
Data requirements, running costs and a clear next step.
Originality5.0 / 10
A meaningful difference from common solutions.

What the judges wrote

GPT-6 AstraPreliminary41/100
Strengths
Your purchase-request example makes the problem of undocumented checks and decisions concrete for operations managers. Your proposed combination of evidence-linked explanations, automation boundaries, and mandatory human approvals gives the concept a useful focus beyond a generic enterprise chatbot. You clearly disclose the synthetic data and avoid inventing performance measurements.
To improve
Your next demonstration should trace raw activity events through workflow reconstruction to an approved purchase output, showing live-model contributions separately from deterministic fallback behavior. Replace the placeholder explanation and unmeasured results table with repeatable tests, specific failures, an approval-bypass test, and a comparison against the current manual process. Specify the production data sources and access controls, estimated per-case running costs, and a realistic first pilot.
Claude Opus 5.5Preliminary33/100
Strengths
Your problem framing is sharp: the gap between the documented process and the real one, with hidden checks, Slack questions and old emails, is a real obstacle before automating anything. Your purchase-request example makes the hidden steps concrete. Your three-tier SAFE / HUMAN REVIEW / HUMAN REQUIRED classification, with approval enforced in the backend, is a sensible design for controlled automation. The 'why does this step exist' explanation linked to policy, decision and incident evidence is a useful twist on plain process mining.
To improve
Your deck still contains placeholders, such as '[Explanation generated by the prototype]' and '[Policy ID]', and every metric cell reads 'Not measured yet'. Run your synthetic purchase-request scenario and fill those cells with real numbers for time, manual steps and automation rate. Replace the generic testing statement with specific test cases, at least one failure you found, and a comparison with manual process documentation or a tool like Celonis. Say which model actually powered the demo, how often the deterministic fallback ran, and roughly what a workflow analysis costs. Give concrete run commands in the setup and name the event data a real company would need to connect.

The team

Ayxan Axundov
developer
Sadaddin Ibrahimli
developer
Huseyn GahramanovLead
product

Disclosure

Required by the rules. Judges verify it against the repository.

Models: Hososhi is designed to work with multiple AI providers, including Gemini, Groq, Cerebras, NVIDIA, and OpenRouter. The providers and models actually used in the final demo depend on the available configuration and testing.
Data: We use sample data to demonstrate how Hososhi works in practice. This includes fictional companies, workflows, policies, purchase requests, and historical decisions. These examples are created for demonstration purposes and do not represent real company records.
Components: The project uses open-source libraries, frameworks, and development tools to build its frontend, backend, and AI integration. Any third-party templates or components used in the final implementation are disclosed where applicable.
Built during the event: Confirmed

Quality testing

We tested Hososhi across its main workflows, AI-powered analysis, evidence, approval process, and automation results. We also checked the backend, frontend integration, and error handling to make sure the application works as expected. For the demo, we created a fictional company environment with sample workflows, policies, purchase requests, and business records. This gives evaluators a complete, consistent scenario to explore and test without needing access to a real company's internal systems or confidential data. The demo data is fictional, but it is designed to demonstrate how Hososhi works in practice. The goal was to make the experience easy to follow, interactive, and realistic while keeping the distinction between simulated business data and real company information clear.

Worth 20 of the 100 points.

Running it

Prerequisites Install Python 3.11 or later, Node.js 20 or later, npm, and Git. 1. Clone the repository git clone <repository-url> cd Hososhi Replace <repository-url> with the actual repository URL. 2. Set up the backend cd backend python -m venv .venv source .venv/bin/activate pip install -r requirements.txt On Windows, activate the virtual environment with: .venv\Scripts\Activate.ps1 3. Configure environment variables Create a local .env file in the backend directory and configure the variables required by the application: AI_PROVIDER=gemini AI_MODEL= AI_API_KEY=your_api_key_here AI_BASE_URL= AI_ALLOW_DETERMINISTIC_FALLBACK=true Replace your_api_key_here with a valid API key for the selected provider. Keep credentials private and never commit the .env file. If no valid API key is configured, supported deterministic fallback behavior may be used instead of live AI responses. 4. Start the backend From the backend directory, run the backend using the entry point and command specified by the project configuration. Confirm that the backend starts successfully before proceeding. 5. Set up the frontend Open a second terminal and run: cd frontend npm install npm run dev If the frontend uses a different development script, follow the script defined in its package.json. 6. Open the application Open the local URL printed by the frontend development server. Ensure the frontend is configured to communicate with the running backend. 7. Explore Hososhi Explore the available workflow analysis, AI insights, evidence, approval flow, and automation results. Functionality depends on the current implementation and configuration. Demo Data Notice Any fictional organizations, workflows, policies, historical decisions, incidents, or business records included in the demo are illustrative sample data, not verified records from real companies.

Project ownership

The team keeps the rights to this project. Judges were given access for verification only.