DES303 Week 10: Developing the Living AI Senior and Planning Ticker Cube

Introduction

In Week 9, Crit 2 helped me realise that Ticker should not become another Motion, another to-do app, or another workplace monitoring dashboard. The clearer project gap is task-aligned verification. Ticker should use task context from existing tools, then ask whether the user's actual behaviour aligns with the task they claimed or were assigned to do.

Week 10 was about making that direction more concrete. I developed the desktop AI senior system, added technical evidence and privacy controls, tested local model and voice pathways, and began planning Ticker Cube as a physical extension for room-based work.

This week was not about claiming that the system is finished. It was about validating which parts of Ticker should stay, which parts should become visible in capstone, and how the system could move from screen-based work into a physical workplace object.

The main question became:

How can Ticker become a living AI senior that talks, asks, learns, and verifies task alignment, while still making the ethical discomfort of workplace surveillance visible?

This week became a development and technical validation week. I worked on two connected directions:

1. Desktop Ticker - a visible AI senior system with focus contracts, feedback memory, privacy controls, technical evidence, voice, local model testing, and context integrations.
2. Ticker Cube - a planned physical extension using Raspberry Pi 5, touch display, and a CCTV-style camera lens so the AI senior can eventually move from screen-based work into room-based work.

The Experience

Week 10 Experiment Frame

Before adding more features, I needed to clarify what Week 10 was actually testing.

The goal was to move Ticker away from:

AI watches → AI guesses → AI warns

and toward:

AI understands context → AI estimates uncertainty → AI asks → user corrects → AI adapts

This distinction matters because Focus Integrity should not be treated as truth. It should be a confidence-based estimate that can be explained and corrected.

Model Evolution: From Detection to Living AI Senior

Ticker has gone through three major model stages.

In Week 7, I was still thinking like a machine-learning problem. I thought that if I collected enough behavioural ticks and corrected the labels, Ticker would gradually learn focus. However, the problem was that focus behaviour changes depending on the task. Reading, writing, coding, designing, watching a tutorial, and thinking all look different.

In Week 8, I moved toward an AI senior / B2B planning model. That gave Ticker more task context, but it created a new risk: if AI creates the plan, assigns tasks, writes the Standard Operating Procedure (SOP), and checks behaviour, then the human may lose freedom.

In Week 10, the model became clearer. The strongest direction is not a strict AI boss. It is a stateful AI senior: a system that understands task context, asks questions when uncertain, remembers user corrections, and adjusts its future judgement.

Developing the Desktop AI Senior Interface

The first part of Week 10 was developing the desktop Ticker interface into something more visible and structured. Instead of hiding the system in the background, I wanted each part of the AI senior to become inspectable.

The desktop system now has sections for:

• Focus
• Timeline
• Feedback
• Privacy
• Settings
• Advanced developer tools
• Technical evidence
• Correction store
• Accuracy
• Research event log
• Voice system
• Local model
• Context integrations
• Brain diagnostics
• Provider health

This was important because Ticker cannot be a hidden surveillance system. If the system is going to judge, nudge, or verify work, then users need to see what it is doing and why.

FIGURE 3 - FOCUS SCREEN: DECLARING THE TASK

Open larger view

This screen is important because it shows a shift from behaviour-first tracking to task-first judgement. Ticker cannot check whether a user is aligned if it does not first know what the user intended to do.

Durable Timeline and Task Activity

The Timeline page shows the durable task activity system. This was a major change from the earlier model. Instead of only reacting during a live session, Ticker now stores task summaries, focus time, correction counts, mis-focus minutes, and status.

This matters because the AI senior needs memory. If Ticker forgets everything after one session, it cannot learn the user's work pattern. The Timeline makes the system feel more like a persistent work assistant, not just a timer.

FIGURE 4 - TIMELINE AND DURABLE TASK ACTIVITY

Open larger view

Feedback Memory: Making Ticker Learn From Corrections

One of the biggest Week 10 developments was the feedback system. In Week 7, correction was mostly a research idea. I wanted users to label whether a segment was focused or not. In Week 10, correction became a visible product layer.

The Feedback page shows:

• questions asked today
• corrections made
• patterns learnt
• false warnings
• uncertain moments
• learnt app/domain patterns

This changes the role of the user. The user is not only being watched. They can train and challenge the system.

For example, if Ticker thinks that "Messages" is distracting, but the user often uses Messages for work communication, Ticker can learn that this app may be related in certain contexts. This does not mean Messages is always productive. It means Ticker should treat it as context-dependent.

This is important because different users work differently. A fixed rule system would be unfair. A student, developer, designer, or manager may all use different tools in different ways.

FIGURE 5 - FEEDBACK AND LEARNING INTERFACE

Open larger view

FIGURE 6 - LEARNED PATTERN STORE

Open larger view

How Ticker Learns Over Time

The new model learns through structured memory rather than hidden model fine-tuning.

This is not the same as saying the AI model is perfectly learning the user. It is more accurate to say that the system around the model is learning. The LLM helps with language and interpretation, but the durable memory helps Ticker adapt over time.

This is a better design direction because user corrections can be edited, forgotten, and scoped. If learning was hidden inside a black-box model, the user would have less control.

Privacy and Permission Boundaries

Because Ticker deals with focus, behaviour, app usage, microphone input, desktop metadata, and possibly camera labels, privacy needs to be part of the interface, not a hidden policy page.

In the prototype, the Privacy page states that the current mode is local summaries only. It also explains that raw screen and audio are not stored unless advanced research mode is explicitly enabled.

This matters because the project is about surveillance. If the prototype secretly stores raw evidence, then the design becomes ethically weak. The user needs to know what is collected, what is not collected, and what each sensing layer does.

Employment New Zealand states that employers must comply with the Privacy Act 2020 and privacy principles when collecting, storing, using, and sharing employee-related information. It also notes that employers considering monitoring, recording, or filming employees should think about morale and trust, and that monitoring must be done in line with the Privacy Act 2020 and privacy principles (Employment New Zealand, 2024).

This directly affects Ticker. A workplace version of Ticker cannot be framed as ethically neutral. It needs visible privacy boundaries, correction rights, and limits on what managers can see.

FIGURE 7 - PERMISSION AND SENSING BOUNDARIES

Open larger view

Settings and First-Run Readiness

The Settings page helped me check whether the system was actually ready for use. It includes voice settings, overlay settings, warning preferences, prompt frequency, privacy level, and a first-run checklist.

This is useful because a system like Ticker has many dependencies. Microphone permission, wake provider, automatic speech recognition, voice output, overlay behaviour, and privacy mode all need to work together.

The first-run checklist also makes the system less mysterious. Instead of failing silently, Ticker can show which parts are ready and which parts still need setup.

FIGURE 8 - SETTINGS AND FIRST-RUN CHECKLIST

Open larger view

Talking AI Senior and Voice Orb States

The most important interaction change was the move from silent scoring into conversation. The text-input overlay is useful for chat mode, but the actual microphone conversation uses an orb interface so the user can read Ticker's voice state quickly.

Each colour has a different meaning: red means idle, green means Ticker is speaking, and yellow means Ticker is listening, parsing, or understanding the user. This makes the AI senior feel more present without relying only on written prompts.

The system should feel alive, but not magical. By "alive", I do not mean conscious. I mean that it feels present, responsive, and context-aware. It can ask what the user is doing, explain why it is uncertain, and later learn from the correction.

FIGURE 9 - VOICE ORB STATE INTERFACE

Open larger view

Idle

Red orb. Ticker is awake but not actively speaking or interpreting.

Open larger view

Speaking

Green orb. Ticker is speaking back to the user.

Open larger view

Understanding

Yellow orb. Ticker is listening, parsing, or understanding the user.

Technical Evidence: Showing Why Ticker Asks

The Technical Evidence page is one of the strongest proof points from Week 10.

In one screenshot, Ticker shows:

• task match: unclear
• uncertainty: 54%
• cache: hit
• deterministic result: unclear
• relation memory: none
• semantic judge: not called
• action: ask_user

This is exactly the behaviour I wanted. The system does not claim certainty when evidence is unclear. It chooses to ask the user.

This is the core difference from the Week 7 model. Week 7 was moving toward detection. Week 10 moves toward uncertainty management.

FIGURE 10 - TECHNICAL EVIDENCE PANEL

Open larger view

Correction Store and Accuracy Calibration

The Correction Store and Accuracy pages make the system more research-oriented.

The Correction Store shows where durable focus corrections and user correction events will appear. The Accuracy page tracks:

• false warnings
• missed off-task time
• uncertain events
• user corrections
• memory updates
• ignored warnings
• over-break check-ins

This matters because Ticker should not pretend to be accurate without evidence. The system needs to measure where it fails and how users correct it.

The National Institute of Standards and Technology's AI Risk Management Framework describes trustworthy AI in terms of qualities such as validity, reliability, safety, resilience, accountability, transparency, explainability, privacy, and fairness (National Institute of Standards and Technology [NIST], 2023). This supports my Week 10 direction because Focus Integrity should not only produce a score. It needs to explain uncertainty, let users correct it, and track how well it is behaving.

FIGURE 11 - CORRECTION STORE

Open larger view

FIGURE 12 - ACCURACY AND CALIBRATION DASHBOARD

Open larger view

Research Event Log

The Research Event Log records privacy-safe system events. It shows decision source, correction rate, memory count, privacy mode, and recent events such as intervention suggestions, brain commands, and voice commands.

This page is important because it allows the prototype to be evaluated as a research system. Instead of only seeing the final UI, I can inspect what the system decided and why.

FIGURE 13 - RESEARCH EVENT LOG

Open larger view

Voice System Testing

I also worked on the voice system. The Voice System page tests text-to-speech, speech rate, voice persona, prompt wording, and interaction mode.

This was important because the AI senior should not only be visual. For the capstone workplace simulation, voice can make the AI feel more present. If Ticker speaks to the user, the system becomes harder to ignore.

However, voice also needs to be careful. If the voice is too aggressive, it feels like punishment. If it is too soft, it may not communicate the workplace authority clearly. This is why I tested different voice personas, including calmer and stricter modes.

FIGURE 14 - VOICE SYSTEM TESTING

Open larger view

Local Model Testing

The Local Model page tests whether Ticker can use a local model route through Ollama. In the screenshot, the model panel shows a Qwen model running through a local Ollama server.

This connects directly to the ethics of the project. If Ticker is about surveillance and privacy, then local AI becomes important. I do not want the system to send every screen, voice, or behavioural signal to the cloud. A local model path supports the idea that Ticker can process some sensitive interpretation closer to the user.

However, I do not want to overclaim this. I am not saying the local model currently solves everything. Local models can be slower, weaker, or less consistent than cloud systems. But testing this path matters because privacy-first processing is part of the design direction.

FIGURE 15 - LOCAL MODEL TESTING PANEL

Open larger view

Context Integrations: Using Existing Tools Instead of Replacing Them

The Context Integrations page links directly back to the Week 9 learning. Crit 2 showed that Ticker should not replace tools like Motion, Slack, Jira, Canvas, or Calendar. Instead, it should use their task context.

In the screenshot, Ticker has a Canvas context panel and context work items such as a GitHub mock task and local Ticker tasks. This shows the direction of the connector layer.

The idea is:

Existing tools hold the work context.
Ticker imports that context.
The AI senior creates a focus contract.
Focus Integrity checks task alignment.
The user corrects uncertainty.
Ticker learns over time.

This is a stronger direction because Ticker does not need to become a full project-management platform. It becomes a task-alignment layer across existing tools.

FIGURE 16 - CONTEXT INTEGRATIONS

Open larger view

Brain Diagnostics and Decision Traces

The Brain Diagnostics page shows that the system is becoming more stateful. It exposes:

• durable read model
• active session state
• recent traces
• recent corrections
• visible mis-focus events
• recovery decision
• nudge runtime
• cooldown
• suppression state

This is important because it shows that Ticker is no longer a loose set of UI panels. It is becoming one system with state, memory, recovery, and diagnostics.

Decision traces are also important. They allow the system to record why it did something. If Ticker asks the user a question, it should be possible to inspect why it asked. If Ticker stays silent, that should also be explainable.

FIGURE 17 - BRAIN DIAGNOSTICS

Open larger view

FIGURE 18 - RECENT DECISION TRACES

Open larger view

Provider Health and Release Readiness

The Provider Health page helped me separate what is demo-ready from what still needs work.

It checks:

• Calendar
• Canvas
• GitHub
• Jira
• Slack
• credential store
• privacy audit
• harness
• external write-back
• model provider
• secret exposure

This was useful because it showed that not every feature should be treated equally. Some parts are ready enough for a design prototype. Some parts are still mock or dashboard-safe only. Some parts, such as external write-back, should remain disabled until there is a stronger approval path.

This is part of good scope control. I should not pretend every connector is fully working. Instead, I should show which parts are working, which parts are simulated, and which parts are future work.

FIGURE 19 - PROVIDER HEALTH AND RELEASE READINESS

Open larger view

Planning Ticker Cube

Why Ticker Cube Is Needed

After developing the desktop AI senior, I started planning Ticker Cube as the physical version of the same idea. The desktop app works for screen-based work, but not all work happens on a computer.

Designers sketch, prototype, assemble, film, write on paper, test hardware, and move around a studio. If Ticker only understands desktop behaviour, it may misread physical work as distraction.

Ticker Cube is therefore not just another camera. It is a physical AI senior object that can sit in the workplace and make the monitoring relationship visible.

The role difference is:

This also makes the capstone more spatial. The project does not only exist on a screen. It becomes present in the room.

Hardware Direction

I considered using an ESP32 first, because it is small and useful for sensors. However, I decided it was not suitable as the main brain for Ticker Cube. I wanted the device to be more like a small local computer: able to run a touch display, camera input, local storage, possible local AI processing, and communication with the desktop Ticker system.

Because of that, I decided to use:

• Raspberry Pi 5
• touch display
• CCTV-style camera lens / C-mount style camera setup
• microphone
• speaker
• physical button or dial
• visible privacy indicator or shutter

Raspberry Pi 5 made more sense than ESP32 because it is closer to a general-purpose computer. The official Raspberry Pi 5 specifications list a Broadcom BCM2712 quad-core Arm Cortex-A76 processor, dual 4K display output, Wi-Fi, Bluetooth, USB 3.0, MIPI camera/display transceivers, and PCIe support (Raspberry Pi, n.d.-a).

For the camera direction, I looked at the Raspberry Pi High Quality Camera because it uses a 12.3-megapixel Sony IMX477 sensor and supports C/CS mount or M12 mount lens options (Raspberry Pi, n.d.-b). This matters because a CCTV-style lens could give better control over the field of view than a fixed webcam.

I also considered future AI acceleration. Raspberry Pi's AI Kit uses a Hailo-8L accelerator and is designed for Raspberry Pi 5, with 13 TOPS neural network inference capability and integration into Raspberry Pi's camera software stack (Raspberry Pi, n.d.-c). I am not claiming that Ticker Cube will immediately run a full local LLM perfectly. However, this shows that edge AI processing is plausible enough to explore as part of the design direction.

FIGURE 20 - TICKER CUBE HARDWARE PHOTOS

Open larger view

Camera module

CCTV-style camera/lens direction for room-based work context.

Open larger view

Pi with screen

Raspberry Pi with touch display as the physical interface for Ticker Cube.

Ticker Cube Technical Validation Matrix

Reflection on Action

The System Became More Visible

The biggest change in Week 10 was that Ticker became more visible as a system. In earlier weeks, I was often talking about hidden logic: scores, ticks, AI judgement, task alignment, and surveillance. In Week 10, these ideas became visible through screens.

The Focus screen, Timeline, Feedback page, Privacy page, Technical Evidence panel, Correction Store, Accuracy dashboard, Research Event Log, Brain Diagnostics, and Provider Health all expose different parts of the system.

This is important because Ticker is about trust. A hidden AI judgement system would be weak both ethically and experientially. A visible system gives the user more ways to understand and challenge it.

The Model Is Not Perfect, but the Architecture Is Stronger

I cannot say that the AI senior works perfectly yet. There are still unfinished parts, including deeper user testing, final connector setup, actual physical Cube testing, and better local model validation.

However, I can say that the architecture is stronger.

The old model tried to make the AI smarter by giving it more responsibility. The new model makes the system smarter by giving it more structure:

• task context
• focus contract
• uncertainty
• memory
• correction
• privacy boundary
• technical evidence
• provider health
• user-visible controls

This changed my understanding of AI product design. Intelligence does not come from one model alone. It comes from how the system is structured around the model.

The Main Shift Is From Judging to Asking

The strongest design change is that Ticker should ask before it punishes. The Technical Evidence page shows this clearly. When task match is unclear and uncertainty is high, Ticker chooses ask_user. This is the behaviour I want.

This protects human freedom. The user may be doing valid work that looks unusual to the system. Instead of assuming failure, Ticker should ask:

Is this still part of your task?

This also makes the system feel more human. Human seniors do not always know what someone is doing from one signal. They ask, learn, and remember.

Ticker Cube Makes the Project More Spatial

The Cube planning also helped me think beyond software. If the final capstone is only a dashboard, people may understand the idea but not feel it.

Ticker Cube gives the AI senior a body. It can sit on a desk, watch the room, speak to the user, and show focus state through light or display. This makes the future more physical and more uncomfortable.

It also helps answer a real limitation of desktop Focus Integrity: not all work happens on the screen.

Ethics Has to Shape the Architecture

Week 10 reinforced that ethics cannot be added at the end. Ticker is about surveillance. Therefore, privacy mode, permission boundaries, local summaries, correction memory, and visible technical evidence are not optional. They are part of the design.

Employment New Zealand's guidance around employee privacy, monitoring, recording, and filming helped me recognise that workplace monitoring affects trust and morale, and that clear policies, consultation, and privacy compliance matter (Employment New Zealand, 2024).

For Ticker, the design implication is:

If the system watches the worker, the worker must be able to see, understand, question, and correct the system.

Theory

Stateful AI and Graph-Like Agent Systems

The new Ticker system is influenced by graph-like AI agent thinking. LangGraph describes itself as a framework for long-running, stateful agents with durable execution, human-in-the-loop support, memory, and persistence (LangChain, n.d.).

This was useful because Ticker should not be one large prompt. It needs state. It needs to know the current task, current session, recent corrections, user behaviour, and what actions are allowed.

This is why Week 10 moved toward a stateful AI senior. The AI is not one magic layer. It is part of a system with memory, policy, and visible state.

Trustworthy AI

The NIST AI Risk Management Framework helped me think about Ticker as a risk system, not just a productivity tool. NIST identifies trustworthy AI characteristics such as validity, reliability, safety, resilience, accountability, transparency, explainability, privacy, and fairness (NIST, 2023).

This applies directly to Focus Integrity. If Ticker says the user is off-task, the user should be able to understand why. If the system is uncertain, it should show uncertainty. If it is wrong, the user should be able to correct it.

That is why the Technical Evidence, Correction Store, Accuracy dashboard, and Privacy pages matter.

Just-in-Time Adaptive Intervention

The sheet and nudge logic connects to Just-in-Time Adaptive Intervention (JITAI) theory. JITAI research describes adaptive interventions that respond to a person's changing context using frequent decision points and tailoring variables (Walton et al., 2020).

This helped me reframe the Ticker sheet. It should not be a random popup. It should appear only when the timing, context, uncertainty, and correction history suggest that intervention is useful.

In Ticker terms:

This theory helped me design Ticker as support rather than constant interruption.

Local-First and Edge Direction

The Ticker Cube hardware planning also connects to local-first thinking. Raspberry Pi 5 is powerful enough to act as a small computer, with camera/display support, wireless connectivity, and PCIe expansion (Raspberry Pi, n.d.-a). The High Quality Camera and AI Kit also show that Raspberry Pi hardware can support flexible imaging and AI acceleration paths (Raspberry Pi, n.d.-b, n.d.-c).

This matters because the project is about trust. If Ticker Cube sends all raw video and audio to the cloud, the privacy story becomes weaker. A local-first direction makes the system feel more responsible, even if the first prototype only uses local summaries and partial local processing.

Preparation

The Integrated Reflective Cycle ends by using reflection to prepare future action (University of Edinburgh, n.d.). For this project, that means the ending of Week 10 should not only describe what I built. It should synthesise what the prototype validates, what it does not prove yet, and how the work becomes a capstone experience.

What Week 10 Validated

What I Am Not Claiming Yet

At this stage, I am not claiming that Ticker can perfectly detect whether a person is focused. I am also not claiming that the AI senior is fully reliable or ethically solved. The Week 10 prototype validates the direction of the system, not the final accuracy of the system.

What I can claim is that the architecture is now stronger. Ticker has moved from a single Focus Integrity score into a visible system with task context, uncertainty, user correction, memory, privacy controls, and technical evidence. This means the project is now better positioned for capstone because the audience can see how the AI senior makes decisions, where it is uncertain, and how the user can challenge it.

Final Capstone Direction

The final capstone direction is a staged AI workplace experience where a participant receives a task, works under a conversational AI senior, sees Focus Integrity respond in real time, can correct the system when uncertain, and ends with a verified effort summary.

The final capstone experience should not feel like a normal software demo. It should feel like stepping into a future workplace where AI support and AI surveillance have merged.

What I Will Test Next

The next experiment should test one complete interaction loop rather than every feature. Nielsen Norman Group describes usability testing as an observational method where a participant performs tasks while the researcher observes behaviour and listens for feedback (Moran, 2019), so this test should focus on whether people understand, correct, and question Ticker.

This test will help me see whether Ticker feels like a living AI senior or just a warning system.

Success Criteria

The next test will be useful if:

• 4/5 viewers understand that Ticker is not another planner.
• 4/5 viewers understand that Ticker checks task alignment.
• 3/5 viewers describe the AI senior as more human than the old warning model.
• 3/5 viewers identify the ethical discomfort without prompting.
• The system asks before punishing uncertain behaviour.
• The user can correct the system.
• The final capstone story becomes clearer.

Conclusion

Week 10 was where Ticker became a visible system rather than just a focus score.

The project moved from Focus Integrity into a broader AI senior experience. The desktop prototype now shows task selection, durable activity, feedback memory, privacy boundaries, local model testing, voice interaction, context integrations, technical evidence, corrections, accuracy calibration, and provider health. These screens matter because Ticker is about trust. If the system watches, judges, and verifies work, the user needs to see how that judgement is formed and how to challenge it.

Ticker Cube also became the next physical direction. I chose Raspberry Pi 5 over ESP32 because I wanted the Cube to be more than a simple sensor device. It needs to support a touch display, camera input, local storage, possible local AI processing, PC sync, and offline-first behaviour. The Cube is not just hardware. It is the physical body of the AI senior.

The main learning from Week 10 is:

Ticker should not try to know the truth of focus. It should manage uncertainty through task context, conversation, correction, memory, and visible privacy boundaries.

This makes the project stronger for capstone. Ticker is no longer just a productivity app. It is a speculative AI workplace system that asks:

What happens when the AI that supports your work also becomes the system that verifies your work?

For the next stage, I need to test whether this system is understandable, believable, and ethically uncomfortable for viewers. The final capstone should not simply show Ticker as software. It should stage a workplace condition where people can feel the tension between support and surveillance.

References

• Employment New Zealand. (2024, March 11). Employee privacy. https://www.employment.govt.nz/fair-work-practices/employee-privacy
• LangChain. (n.d.). LangGraph overview. https://docs.langchain.com/oss/python/langgraph/overview
• Moran, K. (2019, December 1). Usability (user) testing 101. Nielsen Norman Group. https://www.nngroup.com/articles/usability-testing-101/
• National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). U.S. Department of Commerce. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
• Raspberry Pi. (n.d.-a). Raspberry Pi 5. https://www.raspberrypi.com/products/raspberry-pi-5/
• Raspberry Pi. (n.d.-b). Raspberry Pi High Quality Camera. https://www.raspberrypi.com/products/raspberry-pi-high-quality-camera/
• Raspberry Pi. (n.d.-c). Raspberry Pi AI Kit. https://www.raspberrypi.com/products/ai-kit/
• University of Edinburgh. (n.d.). The integrated reflective cycle. Reflection Toolkit. https://reflection.ed.ac.uk/reflectors-toolkit/reflecting-on-experience/the-integrated-reflective-cycle
• Walton, A. E., Collins, L. M., Klasnja, P., Nahum-Shani, I., Rabbi, M., Walton, M. A., & Murphy, S. A. (2020). The micro-randomized trial for developing digital interventions: Experimental design considerations. arXiv. https://arxiv.org/abs/2005.05880