I've been playing with Brad Ross's AISP [1] to get a better quality of llm outputs at strategic stages of our basic design / plan / implementation workflows.
A concrete example of this is our Adviser Skill experiment [2]. In most AI workflows, a "reviewer" agent just dumps markdown feedback. Our Adviser doesn't just "talk"; it outputs an AISP 5.1 document ( a kind of "Assembly Language for AI Cognition" )
This document forces the agent to define:
- Strict Type Definitions for the issues identified (e.g., distinguishing between a gap, an edge case, or a missing requirement).
- EARS Rules (Easy Approach to Requirements Syntax) that determine the verdict. For example, a rule might state: "If any issue has a severity of ⊘ (critical), then the workflow MUST halt."
- Formal Evidence: Every "approve" or "reject" verdict must include a confidence score (δ) and a grounding proof (π) that explains why the change matches the original specification.
By treating the agent's output as a proof-carrying protocol rather than just text, we can chain multiple specialized agents (Architect, Strategist, Auditor) who "triangulate" on the codebase. They must reach a formal consensus where the variance between their scores is low.
This shifts the agent's goal from "Finish the task at all costs" to "Prove that this change is safe and correct." It turns out that iterating on the verification logic is much more effective for building reliable systems than just increasing the number of agents running concurrently.
I've been actively exploring ways to achieve a seamless and natural conversation with an AI.
I played with detecting silences and punctuation ( STT can detect eg question marks ), but this is clearly not enough for turn detection.
I think you made a huge step into that direction.
Did you write an article or blog post about how you trained your model ?
I'd love to make this work with multiple languages, or things like rhetorical question detection.
I'm in the same situation. I found this cog project to dockerise ML https://github.com/replicate/cog : you write just one python class and a yaml file, and it takes care of the "CUDA hell" and deps. It even creates a flask app in front of your model.
That helps keep your system clean, but someone with big $s please rewrite pytorch to golang or rust or even nodejs / typescript.
Our teens problem might be they only value the number of likes on their profile.
Note that I won't get any credit to what I'm saying : I have less than 10 followers.
I'm just wondering if there's a one size fits all solution for authz. I spent a few days on a use case :
- users have one or several roles ( these are hierarchical )
- there are some objects in the system ( hierarchical too, eg files and folders )
- there are different features available according to a user's subscription.
I ended up with a 30 lines program which given a set of rules calculates who can access what in less than a millisecond. Does it worth an over-engineered mega system ?
The problem isn't the 30 lines, though. The problem is "millions of users, billions/trillions of objects" and both are non-hierarchical with pairwise sharing etc.
If the requirements were simple, the POSIX model would still work too :)
I agree. for my use case, once a user is authenticated, you get his roles and subscription. There's a limited number of features or actions for each object type, and a limited number of object types. So you can get the set of rules in the client to manage UI, and apply the same set of rules on the backend in the API.
In this use case the authz calculation time will be the same with a million users and a billion objects.
You are not wrong. And this pattern shows up everywhere. e.g. do you need a SaaS for "feature flags", since they're just an if statement?
In the case of authz, the argument for separating it as a concern is that many applications can share the same scheme, and you can have specialized tools for provisioning, auditing, etc.
Exactly. When you cross a certain complexity threshold, it's worth separating concerns. It's true for configuration, it's true for IaC, and also for authorization policy.
It'd be remiss of us to let left-pad aaS [0] go unmentioned in this thread... For those in today's 'lucky 10,000'^, you're welcome.
There are definitely good arguments for it, services like feature-flagging I mean, and such things are generally relatively low-cost; it's more the risk of adding a 'disappearable' dependency for anything and everything that'd put me off.
(^And if you don't know about this, OMG how can you not have heard about lucky 10k?! Just kidding. [1])
